I'm not following your logic here. If something doesn't need 16 CPUs, why is splitting it over 16 cores a good idea? You're going to be adding a lot of inefficiency, complexity etc for no gain.
Most of mine are dual or possibly 4 core.
One core for OS stuff, other processes etc, one core to do networking IO for me.
As I say, networking IO shouldn't be using CPU. If you're doing long or blocking jobs, pass it over to some other thread. (That's a far better way to utilize multiple cores than splitting the whole networking IO over multiple cores).
What you are suggesting here is exactly what Erlang provides for you. Each connection is a light-weight process inside the VM. The VM then schedules these Erlang processes against native threads. The difference is Erlang has perfected and proven that it can do this reliably over 20 years of development. You would be implementing this by hand, and guaranteed to screw up because its a very hard problem and you are not the smartest person in the world.
Hybrid solutions with Evented I/O and Multi-threading end up being the solution, Erlang is a hybrid out of the box.
Erlang "doing it for me" isn't going to be anywhere near as efficient as me doing it myself.
I'm probably not the smartest person in the world, but I'm certainly smart enough to write a comet/web server that's fast enough.
I guess I'm not going to convince anyone here shrug. If you believe Erlang is a magic bullet great for you.
Furthermore, I don't know where everyone gets off saying erlang is so fast either: I'm not sure where things are now, but last time I checked, their scheduling algorithms were leaving quite a lot on the table, standing to benefit quite substantially from even the most basic operations and logistics knowledge.