That's not a very good idea - you would be creating a bottle-neck for no
good reason. Basically you are serialising the requests from all clients
over a single connection (don't forget that you need to wait until the
response comes back BEFORE you can send the next request).
 
True that it 'stops' all connections at one point (at pound), putting them in a queue--this might not always be bad, though.
The instance when it would help would be if it is farming out requests to mongrel (RoR) instances, which can only handle one request at a time, anyway.  It might be useful for instances when the back-end is a little bit handicap and might get tied up with one request.  It also avoids TCP slow starts within localhost, though that doesn't take much time, and, as you noted, would not allow back ends to do any concurrent processing on requests (like parsing the header while also doing its previous request).
 
The extension of this type of paradigm is having a port to which back-ends can arbitrarily connect to (i.e. any number), and then load balance among them, and this allows the user to fire up more back ends and have them connect, should the load grow (without having to restart).  I wouldn't presume to request that but it's where some proxies are headed :)  Dunno.
 
I'd say it's probably an extension only useful to mongrel users.  Just thinking out loud.  
Thanks
 -Roger