Why is mod_perl 'essentially a hack',

Because:

• you have to tailor your perl to fit it's demands.

  Much of what passes as perfectly good and safe normal (ie.non-mod_perl) code, is unsafe in a mod_perl environment.

• One bad, or memory hungry script can take your entire server down.

Beyond that, I can only quote from one of several comparisons I've read:

Some nice things about fastcgi/speedycgi (http://daemoninc.com/speedyc
+gi/)
*) suexec works with it (I consider this huge)
*) don't have to worry about running multiple web servers (one for
   images/static and one for dynamic).
*) one process can't pollute another's.
*) can make changes to .pm's and they are seen as soon as
   you "touch" the main file. (for speedy, I believe fcgi works
   a little different).
*) bad code doesn't take away the httpd's ability to serve files.
*) can probably be hacked to use internet domain sockets as
   opposed to unix domain so that we can run the cgi's on
   a different box. (fastcgi already does this, speedy does not)
*) the architecture just *feels* better to me than having a perl
   interpreter inside the webserver (but my mind is still open).
*) fastcgi is language independant (speedy is not)
[download]

why would you never use Class::DBI?

Because IMO, it places the code in the wrong place and encapsulates objects in the wrong way.

If you are going to back objects with an SQL DBMS, then the SQL should be in stored procedures and object methods should call those. I was told a long time ago that the secret to using SQL/RDBMSs is in getting the dbm to do as much of the work for you as possible.

Instantiating all your data as objects in your program, leaves you faced wih much higher transmission costs if you update after every local change, or you risk concurrency issues if you cache locally.

As always, that is just my opinion. I am not trying to detract from other's use of these things. Just expressing my own preferences.