I'm sure someone else reading can answer your question based on more experience and expertise than me... anyhow the subprocesses are re-used so there's no overhead in their creation. And if your server is doing I/O bound work (or is just waiting a lot) then it should perform ok. If everything is CPU bound, then you'd want to not create more subprocesses than cores. SilkJS lets you define the number of subprocesses you want.
Thanks for the additional info -- though I would argue that it starts to sound like apache+fcgi (not that it's bad), or unicorn+wsgi... I think node pushes async to an extreme that makes it truly different from what's out there. Unfortunately, it results in leaky abstractions, and lots of misguided enthusiasm as the post goes into...
You could think of pure functional programming (haskell/ml) as a similar extreme -- Haskell gets a lot of concurrency/parallelism guarantees for free just because of how the language was built (pure functions,etc)... Is it wrong to think that node took a similarly crazy step, but in their case, they weren't able to rebuild the language, and that's what you get?
If I wanted to event-loop, or lightweight thread stuff in python, I'd need some libraries, and many of the ones that you might find are not very easy to learn.
More info:
http://silkjs.net/sync-vs-async/