To each his/her own experience:

1. Familiarity: I write as easy SQL as I do Perl, so there is no benefit in "sub-contracting" the SQL side to someone else.
2. Modularity: You can of course only change the internals of your DB-access modules as the interface to the rest of your program must remain the same. Most of the time I find that I need to add some extra bit of functionality, which would break the interface anyhow (or make it horrendeously complicated to enable it to remain backward compatible for all things which depend on it already).
3. Portability: Even with something like Class::DBI you have to set-up a lot of sub-classes for each database, so I hardly see the benefit of going through all that work for each database. I write as quickly my own code (with liberal use of the good ol' copy'n'paste).

Which shows once again that there is no solution which fits and suits everybody. And that's the way it should be!

CountZero

"If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law