Система может опираться на две парадигмы:
- логика на стороне клиента, включая сервер приложений.
- логика везде.
В первом варианте использовать хранимки или view уместно для устранения радикальных проблем с неумением писать sql разработчиками приложения. Во втором случае поводом для хп дополнительно является разделение ответственности, когда каждая сторона замотивирована перекладывать проблемы на другую, или просто говнистый разработчик.
Если сравнивать, можно выделить характерные особенности подходов, зависимые в той или иной степени от СУБД :
SQL - гибок, полнофункционален.
View - менее гибко (ограничения на DML), в некоторых случаях неоптимально (непроталкивание условий внутрь), позволяет инкапсулировать только простейшую логику и некоторые ограничения целостности.
ХП - негибок (разрастание api на особые случаи), изменения требований часто требуют больше усилий по доработке (изменение api nтребует синхронного изменение всех клиентов), можно инкапсулировать сложную логику, общая логика для различных клиентов (это не всегда плюс, когда клиенты хотят немного разного поведения).
Дополнительно можно выделить триггеры, включая триггеры на view, как некий симбиоз подходов. Отличается усложнением взаимной логики при изменении связанных объектов, усложнением диагностики.

Что касается ограничения доступа, то и view и процедуры имеют ограниченные возможности. С одной стороны, они все равно предоставляют возможность изменений, с другой, опираются на критерии, в конечном счете предоставляемые клиентом. То есть полноценно реализуемы ограничения доступа только типа бизнес-логики на основе бизнес-данных.