The root of the problem is that the threads are a scarce resource in the Apache model, and slow clients block those threads, right? In this case the consumers are intentionally slow, but fundamentally it isn't much different than your website becoming really popular with users on bad cell phone networks.
An async architecture based around epoll would certainly make the thing scale much better - I've worked on systems that could handle 100,000 idle (or extremely slow) http connections without meaningfully impacting the performance of a few hundred live ones. Such an architecture is even mentioned on the apache-dev link that is provided in the article, so its not like that's news.
But that kind of hand-managed parallelism development style is what a thread is meant to abstract away. The real question to me is why threads are such a scarce and/or unscalable resource?
Specifically, I am curious to know what happened to all the talk of linux 2.6 and 100,000 concurrent threads from a few years back: http://kerneltrap.org/node/422
Should the default config be cranking up the max number of thread allocations (and the default stack sizes for them down), and if not - where is the bottleneck that prevents that?