use the right tool for the right job. If a project required fast processing or high levels of concurrency, I'd probably use something like Go or Rust (both great languages in their own right). Again, Node does certain things well and those things are useful for my line of work.
Easy to Learn
Tooling and Packages
Depending on who you are, this can either be a good or bad thing. Node has a package for virtually every problem one would wanna solve. I've used QR code generators, I've used AWS interfaces, I've used really lightweight http servers, and I recently started playing with a decentralized status page that takes advantage of the IPFS protocol (the internet is a cool place!). The good thing about all these packages and tooling is that it's easy to get up and go. Solving a problem and completing a project can be done really quickly because everything doesn't have to be hand-coded.
There are cons however. It can lead to dependency hell, it can make developers solely depend on third party tools that they don't understand, and too many misunderstood, unknown, third party packages can violate and undermine the integrity and correctness of a software project.
Reduced context switching
This is particularly specific to web developers. I don't like the term "full stack developer" because I think the connotations imply that someone is an expert at each level of the development stack which seems disingenious to me. I dunno, maybe this rockstart unicorn dev exists, but I haven't met anyone like that. However, Node lends itself a little bit to the "full stack" concept in the way of reduced context switching.
Switching between programming languages carries with it a cognitive load; there are ideas, rules, and concepts that a developer has to switch between when alternating between programming languages. Personally (and anectdotally) I worked in a dev environment where the frontend consisted of Ember.js and the backend was combination of legacy PHP and .NET/C#. It was... painful, to say the least. More than once I made the mistake of using a PHP or C# specific function in our frontend, or vice-versa. Constant context switching can impact performance, affect developer well-being, and introduce all sorts of issues into a code base.
Node is relatively young in regards to programming languages. Because of this, the tooling is immature and not as well-established or battle-tested that it could be. By now, most of the ugly parts of Java or C++ have reared their gross heads; issues have been mitigated, workarounds have been put forth, and best practices have been established, revised, and established again. Node doesn't really too much of that. These best practices and concepts are artifacts of decades old programming languages. Node can be a bit of a wild-west. This is both exciting and a little frustrating.
Best Practices and Development Time
Because Node is a young programming language, best practices haven't been cemented in the collective unconscious of the Node community. There is not really a definitive best way to do X. Again, this can be exciting because solving for X leads to greater understanding, but it can really slow down development time. This cost of dev time vs. exciting discovery can be detrimental to projects that are trying to hit the ground running.
High Performance and Heavy Computing
Anyone that has installed an electron application can bear witness that Node's isn't exactly the most performant runtime in the world. Anything that requires long-running calculations, minimal memory usage, or heavy computations aren't suited for Node. Especially because of it's single-threaded nature. I have come to appreciate the event-loop and the async/await paradigm, but neither of those things really lend themselves to faster and more performant computation.
I like Node, even with all it's shortcomings. I can say that it's lead me to becoming a better developer, and it's enabled me to write fun and interesting code. I like most programming languages actually. Each is unique and offers a different perspective on the science of technology and computing (which is fascinating). After having written what's essentially an essay on Node, I think Bjarne Stroustrup can best sum up how I feel about node:
There are only two kinds of languages: the ones people complain about and the ones nobody uses.