Not just more difficult. Threads are really wasteful to spawn just so you can hit 10 shards. Even if you have a thread pool. Evented I/O is much better than threads.
When NGiNX launched, it was the evented web server in a sea of threaded servers. Guess which paradigm won.
It's not a dichotomy. The answer is that both models are useful, and most systems support hybrid threaded and evented modes. Node.js only supports one model, which is a huge drawback.
In PHP and other scripted web server languages? Please show me how it's done.
PHP does preforking first of all. You have about 30 "threads" sitting around, able to handle 30 clients. This is STILL not the same as evented programming, which lets you send out these requests and wait.
Speaking of -- have you ever heard of evented i/o?
Let me put it this way ... threads and workers are good for handling incoming requests (one worker per request). But for outgoing requests, it's nice to have evented i/o!
Threads do have a cost in terms of virtual memory, but on 64-bit architectures, this is a non-issue.
Optimizing for "C10K" (which, btw, was a big number in 1999, not today) by using an event loop will actually harm latency and performance in the case that you are dealing with a small number of highly active connections. Believe it or not the kernel can do just as good (or better) a job of scheduling than Node's event loop.
Have you ever heard of threads?