There is one case I can think of --- a site which mostly serves static
content, but has a few complex, lightly used CGI scripts (e.g., for
handling administrative or authoring functions) might be better off
leaving them as CGI.
In general, use of server APIs fattens up the server, and that can
chew up lots of RAM on a busy server, taking it away from file system
caches (and even causing swap-space thrashing if you're really
unlucky). Apache and mod_perl in particular can bite you this way if
you aren't careful, and the mod_perl tuning guide has quite a bit to
say about dealing with the problem (http://perl.apache.org/tuning/),
mostly by running requests for static and dynamic content out of
But if the scripts aren't invoked much anyway, you might as well
run them out of an otherwise static server as CGI --- it doesn't
matter if they take a little longer than they need to, in that case,
just so long as they don't gum up the works for the requests that do
need to run fast.
But that's got nothing to do with big iron per se, of course...