Even if you only get to work closely with a DBA, what you say has a lot of truth.

With many OO wrappers you lose the ability to readily take the generated SQL and test it outside of Perl. It also becomes hard to take the SQL to a DBA when trying to figure out performance issues. Or the other way around when the DBA says, "These are our most expensive running SQL statements..." - does no good when you can't find the query.

So by all means find ways of modularizing your code so that the SQL is not strewn throughout. That is just common sense. But the use of an OO abstraction layer might or might not make sense for you.

Just because someone else thinks that the approach is worthwhile, and has gone through the work to implement it, does not mean that it will be the best solution for you. Understand the costs and benefits, then decide appropriately for your situation.

I like your analogy to templating. Because the fundamental issues are pretty much the same. As I pointed out in Re (tilly) 6: Code Critique, there are many possible solutions, and depending on your circumstances, any could turn out to make the sense for you. Until people start thinking in terms of the trade-offs, they don't have a hope of guessing what the right one is going to be for them.