In my (warped) view of history, Class::DBI was created to do two things - first to allow easy row-based manipulation of database entries, and second to allow triggers for databases which don't have them.

I recently started reading Celko's "SQL for Smarties", and he uses triggers and constraints quite a lot, which is news to me, but I think I understand the rationale behind it. Constraints are like taint mode in Perl - they prevent the database from containing data that violates the assumptions. Triggers are a nice thing to have as soon as you start going from row-oriented manipulation of your data (read-modify-write) to set-oriented manipulation (UPDATE foo SET bar=baz WHERE ...) - here, triggers are the only way to specify a separate action.

In the end I guess it depends on what you do. I wouldn't go as far and put stored procedures into the database - this means that the "actual" code is distributed over too many (two) components. But I really like specifying my reports in SQL, because SQL makes it so much easier to formulate aggregations than Perl.