100req/sec * 7 mongrels => 700 req/sec total. and other simple math.
they aren't spawned automatically. you setup a number and distribute to them. there are ways of getting them to spawn automatically, but it isn't inherent to mongrel itself.
It seems to me the webserver would then need to support that (dynamic allocation of additional target mongrels).
The way it works currently is you put Apache2 / Lighty / nginx / etc in front, working as a proxy, which has a list of host/port pairs which it forwards on the request to.
The proxying end of things would have to be smart enough to tell mongrel to startup more processes, and begin forwarding more requests to those.
I love Rails, but those guys are too anxious to throw the Apache baby out with the PHP bathwater.
At the same time, it's trivial to switch this number if you've not hit your server resource limits yet. (i.e. when coming under a digg load)
Once server limits are reached (in Apache or nginx/mongrel/rails), the point is moot - you'll have to instantiate new servers at your co-lo / hosting company by hand anyway.
All that said, nginx is a fantastic web & proxy server. It blows Apache out of the water in terms of memory usage, etc.
My point is that the application processes are where things are tricky. Even 'big slow apache' can saturate fast connections with static content. The real trick is to get the most out of your dynamic code without under utilizing your resources (by launching only one mongrel instance, for example), or running things into the ground by letting your apps try and grab too much memory.
mongrel doesn't do it for the same reason tar doesn't support encryption (pgp does!).
mongrel is designed to serve requests, not balance requests or spawn itself. sure it could, but it doesn't have to. it is just as easy to have another project spawn more mongrels. That way if I want to to write software just for looking at my servers and making more mongrels, i can, very easily. Otherwise i have to look in mongrel's code.