Они мешают локализации бизнес-логики внутри вашего приложения. Т.е. бизнес-логика разделяется на две части и на два языка программирования. Рассмотрим каждый из недостатков по отдельности.
1. Бизнес логика разделяется на две части. Этот недостаток особенно проявляется при использовании веб-фреймворков и в частности паттерна ORM. В паттерне ORM при создании, обновлении, удалении объекта через шину событий вызываются обработчики события, в них и пишется бизнес логика, а хранимые процедуры этого лишают. Хранимые процедуры дают оптимизацию и у программистов есть недостаток к преждевременной оптимизации, что может привезти к резкому усложнению архитектуры и кода.
2. Бизнес-логика пишется на двух языках программирования. Во-первых нужно знать, хорошо знать, два языка. Во-вторых, нужно вводить Coding Style Standarts еще для одного языка. В-третьих, языки хранимых процедур (T-SQL, PLSQL и т.п.) не очень подходят для написания сложной бизнес-логики, а современные требования к бизнес-логике как раз требуют софистики. Вообщем код получается запутанным, нечитаемым, сложно модифицируемым и т.д.
Я признаю только триггеры, только util-триггеры. Например, триггер запрещающий удаление записей в определенной таблице, это можно сделать с помощью прав, но лучше дополнительно защитить триггером который будет распространятся глобально на всех пользователей. Второй пример, это триггер подсчета количества записей в таблице, как известно COUNT(*) на больших таблицах обходит весь индекс по PRIMARY KEY, а вообще большие таблицы зло - лучше сразу шардить.
P.S. На опыте скажу сталкивался с системой КИС УЗ Модус, разработчик отказался разрабатывать сервер и запил всю бизнес логику на T-SQL и вызывал их из клиентского десктопного приложения. Вообщем печальная была система.
