Speaking as a Dev rather than a DBA I personally think triggers are the work of the devil. Mind you, that opinion's probably utterly unfair and mostly informed by the fact that I've worked on way too many systems where triggers were used to implement business logic. In terms of business logic I want the database to be as dumb as a plank.

I do believe, on the other hand, that the database should be responsible for retaining it's own integrity so if triggers are necessary for that (I'm not 100% convinced that they really are but there's always an exception) then fill your boots.

On auditing, I think it's a grey area and really depends on the nature of the audit. If it's about detecting and tracking change at the database level then a trigger's probably the best way to go. If it's about producing a more "Businessy" audit that's likely to be consumed by users on a regular basis, then I think I'd probably argue for it to be implemented in a separate Business Logic Layer.

All I'd really ask is this: if you're going to implement a trigger, then do so in such a way that I can do anything I could reasonably expect to as a dev (including directly updating data when the marketting department are breaking down in tears becasue they accidentally imported 1000 new customers under the wrong reference), in total ignorance of the trigger's existence, without accidentally bringing the world down around my ears. Preventing me from carrying out an erroneous action is fine. Allowing me to carry it out and then generating a bunch of new records and updating some aggregated values to a comletely garbage value isn't. I have alot of sympathy for the "you should have read the docs" argument but I can only retain so much knowledge and I've often found myself in situations where the time to check the documentation is a luxury that is unavailable to me for reasons that are out of my control. I'm not dumb or lazy... but it's probably a good idea to assume that I am.