No. The main problem the event MPM addresses is HTTP keep-alive.
With pre-fork and threaded, every connection takes up a process or thread. This sucks for keep-alive because it can take a while before the client issues the next request.
The event MPM puts that idle connection in a kqueue/epoll/etc. pollset and recycles the process/thread for another request.
It's a conceptually simple change but it has some profound performance implications.
As a single datapoint, I run a site that handles many billions (this is not rhetorical or an exaggeration) of hits per month using mpm_event: I consider it the only sane/stable way of configuring Apache.
As I found out to my sadness, the only sane configuration is not the one which ships with apt-get apache2.
I like many things about Nginx. The fact that it is a production-capable web server out of the box, for example. I know that is probably not a high-priority design goal for Apache for historical reasons, but it seems a very sensible default in 2011.
For the record, "apt-get install apache2-mpm-event" is all you need to switch to mpm_event: I believe it isn't supported on all platforms, and, as a conservative Debian-based distribution using apt-get, I'd prefer "predictable behavior across all of our targets" over "highest performance configuration on any given system".
(I also believe there are some corner cases where mpm_event may burn you on 2.2, and both Apache and Debian are going to play it safe there; but, when I looked into this in detail a forever or so ago, I determined that whatever issues they were didn't apply to my setup. As an example: if SSL were an issue, I doubt I would ever use Apache to directly serve SSL anyway, as that's what SSL accelerators are for.)
That said, I still wouldn't leave the defaults in place with regards to "number of servers / threads"; although it isn't like nginx doesn't need the same configuration: the default value of worker_{processes,connections} is almost certainly inappropriate for your specific setup. I also use nginx (as a load balancer), and I have those values at 64/10096, up from the Debian-default of 1/1024.
The important thing, to me, is what a technology makes possible, not how well it is configured out of the box. Example: it is more damning to me that nginx only does HTTP/1.0 to upstream servers it is proxying for, a reasonably fundamental limitation of the codebase, than any transgression they could make in their default configuration.
Seriously: production is not about "out of the box", it never was, and it likely is never going to be. If you are trying to run a production server using "out of the box" defaults you are going to be forever disappointed by the performance and functionality of the offerings.
We (as a civilization) simply do not have the science and theory yet to make the practicalities of setting up and maintaining anything at this level of complexity a totally seamless and simple process with well-understood performance characteristics unless you constrain absolutely every single variable.
If you are trying to run a production server using "out of the box" defaults you are going to be forever disappointed by the performance and functionality of the offerings.
I have sold hundreds of thousands of dollars of software to thousands of people which has run for years without (web-server related) incident on nginx. If I am fated to be struck down for my ignorance of nginx internals, that doom must be further down the road.
Where I do see failure is when I put the world's most popular blogging software on Apache, turn on caching and give it a gig of RAM to play with, and then watch the server get denial-of-serviced by the totally innocent actions of any ten readers attempting to access the website in a 15 second interval. Thank you, KeepAlive. Ten is not a big number on the Internet. Apache has been DOSed by my younger brother's comic book writing advice blog.
I accept that, for historical reasons, the Apache project does not optimize for being useful without being a master of arcane trivia like knowing what options the server is compiled with (!) to be able to operate a college student's blog (!!) without falling off the Internet. Much software developed these days pitched at web developers, including software which I write, has as a guiding design principle that you should be able to start using it in five minutes following simple instructions and those sensible defaults should mostly work. I think this development model is categorically better than software-by-the-experts, software-for-the-experts models.
P.S. apt-get mysql gets you a database which won't fall over if you try to host a comic book blog on it.
I'm sorry, but I've never tried to run a comic book blog. I have, however, had nginx taken to its knees with the default configuration on a system that could trivially handle the load it was receiving, requiring modifications to the exact same parameters one has to reconfigure after doing an apt-get install apache2-mpm-event to get good performance.
Frankly, it seems like your real issue here is that no one told you to apt-get install apache2-mpm-event instead of apache2, and if anyone would be to blame regarding that it would be Debian/Ubuntu (you will note I specifically stated "if I were a conservative Debian-based distribution using apt-get", not "the Apache project").
Again: this isn't a problem with the default configuration, this is you installing the wrong thing. From my perspective you may as well be complaining that you typed "apt-get install apache" and got Apache 1.3 (yes, I know this doesn't actually happen on Ubuntu: it simply doesn't work), when that "should" have given you Apache 2.x.
In 2.2, the event mpm doesn't support ssl, but in 2.3/2.4 it does support ssl.
In fact, IIRC, if you are using apche as a reverse proxy (mod_proxy) the event mpm should become the standard as it will detach the worker thread both for keepalive on the front end, and when waiting on response from the backend.
With pre-fork and threaded, every connection takes up a process or thread. This sucks for keep-alive because it can take a while before the client issues the next request.
The event MPM puts that idle connection in a kqueue/epoll/etc. pollset and recycles the process/thread for another request.
It's a conceptually simple change but it has some profound performance implications.