Было много написано о вреде триггеров.

Медленные, плохо понятные зависимости, дедлоки, и т.д.

Вместо триггеров часто рекомендуют написать API на таком же pl/sql, который будет делать то же самое, только теперь к таблицам надо доступаться через API а не через операции SQL. И версий этих API может быть много:
InsertRowAndUpdateTotals()
InsertRowAndUpdateTotalsEx()
InsertTwoRowsAndUpdateTotals()
....и часто без документации.

Как наши умудрённые опытом форумчане относятся к использованию триггеров в своих проектах?
Избегают любой ценой как клятого goto, или выработали правила их разумного применения?

Я заметил в своем проекте триггеры стоят не на таблицах, а только на некоторых представлениях. Не знаю, популярный ли это прием, но он устраняет или по крайней мере ослабляет многие доводы против использования триггеров.
Такое представление становится объектом-интерфейсом, который поддерживает стандартные методы sql и реализует малую толику бизнес логики.

А к таблицам остаётся нефильтрованый доступ если надо.

С логгированием и отправкой сообщений в очередь понятно - видел такое в работе, и это действия которые должны осуществляться за короткое предсказуеморе время (хорошее общее правило для кода в триггерах, как и для кода прерываний: минимум задержек, нежелательность ожиданий на общих ресурсах).

> общие операции с данными таблицы
А какой был бы хороший и нередкий пример здесь - проверка данных? Обновление статистики?