Slow clients hold the process so you'll have to open a new process to serve someone else which DOES increase the cpu/ram usage as explained before.

Apache still used preforked servers last I checked. That means it children aren't created in response to requests. Either way, you can definitely set a limit on the number of processes that can exist at a given time with Apache.

I'm not ignoring the specifics that apply to PerlMonks

You just indicated that if it's good for Google, it's good for PerlMonks.

which are probably caused by slow clients holding up children for long time

If you have too many children, it's because you set the limits on the number of children too high.

Faster page delivery means less process have to run together which will lower CPU load ... that's my point of view.

Sorry, but it's wrong. CPU load is not related to the number of processes. You could have a thousand processes using no CPU, and you can have one process using all available CPU.

Faster page delivery means fewer active processes, which could lower CPU load and context switches. As I alluded in my first post, the question is can the savings offset the increase in CPU load and context switching incurred by zipping everything.

If there really was a problem with long lived children, I imagine using an appropriate proxy would be a much better solution than zipping. (It might even be worthwhile for the proxy to zip responses.)