Is it really an advantage?
From the article:
"Whereas a Java process would suspend further operations until a database query had been answered, Node.js's non-blocking system continues to execute commands and get work done while the query is going on."
Java code is almost always executed in a web application container like JBoss, Tomcat, Weblogic or WebSphere. Those servers have thread pools that service a configurable number of concurrent HTTP requests (based on the number of cores in your server, each core's speed and total server memory). They also have connection pools that allow for a configurable number of concurrent DB operations (depending on the strength and type of queries issued to the DB server).
When analyzed on a deeper level, this statement seems to be a six to one, half dozen to another subjective call. Both environments allow more than one thing to happen at a time but they achieve it through different architectures. I fail to see how or why an asynchronous callback that must end up processing the work via a pool of synchronous threads, is any more efficient than having an up-front thread pool of synchronous threads.
I also fail so see why one architecture would be more efficient than the other. In fact, the asynchronous programming model looks hideous and even the article mentioned it's a pain to debug. The up-front thread pool model where each thread blocks on synchronous, relatively long-running requests seems more straightforward to program and for the life of me, I'm not sure why anyone would hail the asynchronous architecture as an advantage.
While developers can make a mess with anything, it seems Node.js is returning to where the web began and we evolved from that to more complex architectures. Maybe we went too far (I often think that) but what does Node.js offer that makes it a "back to the future" alternative?