I see this arguing often appear and I think it is focussing on the wrong points. In every domain mentioned both Node and the competition have strong reasons of why to use and those reasons transform over time and expertise.
I.e. take the performance argument: a common assumption is:
Go > Java > Node > Python > Rails > PHP
This holds true for parallel processing or Node.js’s async loop: In every programming languages you have tools that easily destroy every advantage gained through other features. A good example for this might be transactions in the DB access layer: Applied wrong it can crush any memory advantage.
But even if you put this aside, the CPU/Memory and I/O throughput of all these systems are limited. Once you need to scale beyond the hardware , factors such as compose-ability and distributability become a much bigger question. Which means this whole discussion is just about shift of the point-in-time when you need to deal with those complexities. A particular paint point is the Chat example: Depending on the Scale and latency of an Application, you will likely use Erlang rather than Node.js for something like an international MMORPG.
In my opinion we can do better. The approach I usually take to explain the advantages of Node.js uses different angles. I try to focus on the points where Node.js can objectively be set apart from other languages.
Micro tasks — Zeit.co/now, AWS Lambda, Google Cloud Functions and Azure Functions all have Node.js as first class citizen. And not for no reason: Node.js functions are good to sandbox and execute in a context. These stacks allow you to quickly modularize your application and both scale and distribute them effectively and globally, other languages are often missing and even with Docker are by far more painfully. (Docker is not easy)
Compose-ability — Node.js has very simple, well documented and sufficiently well performing I/O capabilities for a wide variety of protocols! The Linux process I/O is quick, tcp and udp are well implemented and http is at its core. It also has some very well performing websocket implementations. This means that if you ever run into an issue where Node.js is not comfortable or doesn’t fit: it can quickly become communicate with any other service. The I/O in many other languages (like PHP or Java) can become significantly more bothersome.
Time to Market — Electron is by now known as being very memory intensive and not always tests great with users but it allows to extremely quickly build applications which makes it very attractive if your solution is time-sensitive. This holds true for both almost every problem domain: Web Services, IoT applications, Desktop applications most of those can be built in a very short time compared to other technologies.
Downsides on the other hand should be mentioned as well and I feel the following sections are much clearer cut than the examples mentioned above.
A/V Processing — Even though there are bindings to OpenCV or GraphicsMagick: handling image, audio or video data with Node.js quickly becomes problematic. It is probably still more comfortable than PHP but you quickly run into limitations of the given libraries. They are simply not as well as their C, Go or Python counterparts. This particularly holds true if you want to render complex graphs or videos in a context other than HTML.
Scientific Programming— SciPi (Python), MathLab and Rust have made names for themselves in the science community because they are fast and offer far more than is currently available on NPM. Everything but some specific domains are better covered by alternatives.
Embedded Programming — Other than for prototyping, the VM simply is at the moment not suited for embedded programming. Garbage collection, startup speed and memory consumption quickly surpass anything available in a low-spec environment.
CMS — The CMS systems available in other programming languages (Particularly PHP) are in many cases far further developed, have a broader community than anything I have seen in Node.js so far and allow for quicker setup of custom systems.
Last but not least I am missing a section that is easily overlooked when recommending Node.js, namely: Where Node.js is not a problem! This is important because the years have resulted in prejudice against the platform.
Security—Node.js has fast and varied ways to test anything. There are public security companies and relatively good policies in place. The ssl implementation are always up-to-date. The tools available encourage good security settings. The Database layers are generally written after SQL injections have become general knowledge so they usually don’t have the same issues as older counter-parts. Generally: if you run into a security issue then it is likely for a reason that wouldn’t be prevented by other platforms as well and usually they are fixed with much less effort due to the excellent capabilities of NPM.
Longevity — A good majority of NPM packages support Node.js 0.12 which has been published 2 years ago. But more importantly: Semver has been adopted in many Node.js communities and they allow both upgrading and maintaining projects without much pain. It should be pointed out that many of the libraries found on NPM come with git links that you can clone if an error should occur — something not necessarily true for all other languages. And while it is true that the eco-system changes quickly: The Node.js core API has stayed mostly stable.
I feel like this could be more usable than the explanation above, do you disagree?