Node.JS's most significant advantage is its non-blocking nature. It's single-threaded, so it doesn't need to spawn a new thread for each new incoming connection.
Behind the event-loop (which is in fact single-threaded), there is a "Non-blocking Worker". This thing is not single-threaded anymore, so (as far as I understood) it can spawn a new thread for each task.
Maybe I misunderstood something, but where exactly is the advantage? If there are too many tasks to handle, wouldn't the Non-blocking Working turn into a Blocking Worker?
You need to read about libuv, the "magic" behind node's non-blocking I/O.
libuv tells the OS that it would like to know about any changes (connection state, data received, etc) that happen on a particular set of sockets. It is then up to the OS to deal with managing the connections. The OS itself may create one or more threads to accomplish that, but that's not our concern. (And it certainly won't create a thread for every connection.)
For other types of operations like calls to C libraries that may be computationally expensive (ie crypto), libuv provides a thread pool on which those operations may run. Since it is a thread pool, again you don't have to worry about thread count growing without bound. When the pool is fully busy, operations are queued.