Just because lots of people say "non-blocking, good concurrency, event-based model" without understanding it doesn't mean it's not correct. With a single-threaded, event-based model, you can get an awful lot of concurrency at reasonably consistent latency without ever thinking about threading issues or managing thread pool size to balance memory and concurrency -- and often with less memory, too.

Yes, there are downsides: it's not a natural model for many people; you do still have to consider many complex concurrency-related issues; and control flow libraries are usually needed to make complex code much more readable. But these are either easy to deal with or intrinsic to the complex problem at hand, and the above still stands: once you understand how to program with this model, the "default" implementation usually scales very well.

Yes, Node was not the first to do this, but that's not relevant to anything.

Besides all that: I'd put Node's postmortem debugging and dynamic tracing capabilities up against any other dynamic environment.

As a side note: it's enormously condescending to tell people that a very broad technical choice is not only wrong for their technical problem -- without even knowing what it is! -- but that they're also part of some mass delusion for even thinking that there's anything to it. I hate arguing about this stuff. You keep trashing Node, and we'll keep using it to build large distributed systems.