Whilst you raise some interesting points, you fail to mention common workarounds that are deployed to deal with the problems you mention. I have found mod_perl does a great job as a high-performance Web application server.

FastCGI achieves greater speedup by keeping a user-defined number of processes for all requests to be processed by. mod_perl, on the other hand, tries to equip every web server with a fully fledged copy of Perl.

On any operating system I've used, the fully fledged copy of Perl is shared between all httpd processes using copy-on-write memory. This isn't a problem.

If a web server is just serving a flat file, that Perl instance is taking up memory but sitting idle.

The mod_perl guide describes various strategies for dealing with this. Reverse proxying is commonly deployed using a lightweight Apache httpd or Squid. Or you can use a separate httpd, configured differently for serving flat files such as images. Furthermore, you can load your code into memory when the parent httpd starts up, ensuring that code is shared between child httpd processes.

Some of the statements are just plain incorrect, such as "need to reboot httpd when script changes on disk" - for mod_perl this is a cronic problem

On a development server, you can use Apache::Reload to avoid such problems. On a production server, your code shouldn't change frequently, anyway.

And what about memory leaks? mod_perl has no recovery.

True, but it's easy to avoid most memory leaks in Perl by using good programming practices (use strict, use warnings, etc.).

Additionally, mod_perl integrates much tighter with Apache than FastCGI. If you're just using Apache::Registry, you won't notice these benefits, but if you write your own mod_perl handlers, which is simple enough, you can hook into the different request phases and other features of Apache. Now I've written handlers, I find it hard going back to the plain old CGI way of doing things for major projects.