Non-blocking evented IO is mostly attractive from a usability point of view: it's much easier to write programs that aren't multi-threaded. It can also use much less memory than a threaded model in certain situations.
Non-blocking, evented systems tend to be single-threaded. Single-threaded systems don't automatically scale across multiple cores. To scale, you spawn a separate process for each core (for example, this is the suggested practice for node). You must then find some way for the different processes to communicate with each other, which is usually through a database (or some crazy pub-sub thing).
Node can scale just fine if you design your program to do so. It just scales in a different way.
Personally I love it, but some programmers find non-blocking evented "async" IO completely counter-intuitive. So it's debatable on the usability.
Async IO is an absolute win from the scalability perspective because it allows you to service a great many clients with many fewer threads. OS thread context switches are relatively expensive. Ideally you would have exactly one OS thread per physical core and they would never need to block on exclusive access to any shared resources.
Now that we have a system where the user code inside the async handler doesn't need to manage exclusive access to anything, from the usability perspective it can has some of the simplicity of code that is fully single-threaded. But that's subtly different from saying ASIO makes it easy.
My guess is that many of the same programmers who aren't comfortable writing multithreaded code aren't going to find it completely intuitive to rethread their stack around an ASIO model.
If you're working on a project where I/O blocking is your primary performance issue, Node has a lot to offer in the form of a framework that helps and encourages you to structure your code in a way that works well for such tasks. Javascript's performance and its being single-threaded will have minimal impact, because those concerns are absolutely dwarfed by I/O costs in the situations Node's designed for.
On the other hand, if you're worried about how many threads you can run at once, then you're working on a task where CPU performance matters. That's not what Node is designed for. If you use Node anyway, you've decided to try hammering screws into place - and you should absolutely expect that it won't work out very well for you.
Essentially the first one is most right. Non-blocking IO can get a lot of work done as it is never hindered by doing nothing while waiting around for slow IO. It never blocks so it can always do work.
However, if a non-blocking system has too much work to do it can still max out a CPU. At this point you, ideally, need as many worker threads as you have CPUs.
However, a threaded system that doesn't use non-blocking IO runs the risk of having many blocked threads eating up a CPU & memory instead. This is largely dependent on the light-weight-ed-ess of the threads.
Both these systems are effected by how much work the server has to do to create a response, thus even non-blocking IO can become swamped if it uses a slow language, too much memory or the wrong algorithm, plus all IO must not block or else the non-blocking networking ends up waiting around for blocking files.
There are other complications too like the number of file handles a process can issue that can also impede a server and the number of clients it can simultaneously serve.
It depends largely on what your scaling issues are. If you have requests that take a long time because of waiting for replies from web service calls, database calls, and the like, it will be a huge boon to scalability. If your CPU-limited, on the other hand, the non-blocking IO won't help you.
I think largely non-blocking I/O is a means to an end. Non-blocking I/O allows one to implement a single-threaded event loop, which allows one to skip all the overhead associated with multithreaded systems. It's not the non-blocking I/O which necessarily makes it more scalable, it's the fact that you avoid the heavy cost of context-switching and the memory and CPU complexity of thread creation.
* It uses non-blocking evented IO so it can scale well.
* It is single threaded so it can't scale well.
Someone teach me: which of these statements is true?