Triggers, in my experience, are best used sparingly and with careful forethought. Triggers that reference other database objects add complexity to query plans.
I worked on a system (in DB2) that had huge numbers of triggers on improperly designed tables, and which had multiple schemas for stupid business reasons. You'd have a main order table with about 20 triggers on it - changes to this table cascaded through those triggers to probably 10, 12 tables, each of which had multiple triggers that cascaded change to tables that had triggers that cascaded change... to make matters worse, if you have multiple schemas with identical tables, the optimizer can't determine which one will be affected and so the plan has to take all of them into account, each with THEIR triggers.
We actually had developers write stored procedures that couldn't be compiled because there wasn't enough memory on the server to prepare the plan.
Triggers are indispensable in some (relatively rare) cases, and should be avoided at all other times.