Kachalovя считаю что для "серьезной системы" вообще ХП не нужны. Кстати что Вы называете "серьезной системой"?Все просто - как разработчик (ну совсем не DBA), я достаточно сложной считаю систему, для которой имеет смысл распределять работу хотя бы традиционно на троих :) - БД, апп-сервер, клиент. Тогда каждый кусок есть черный ящик для остальных, и своя логика, от остальных независимая, есть в каждом.
И при нормальном проектировании тогда логика обработки, формализуемая в реляционных терминах, естественно живет внутри СУБД, объектная - внутри апп-сервера. И противопоставлять их друг другу - просто бред.

Kachalovто очевидно что подавляющее большинство таких систем относится к типу OLTP-приложений, которые прекрасно могут обходиться без ХП и где использование ХП означает скорее архитектурную безграмотность разработчика, а не реальную необходимость.Безграмотностью разработчика в любых системах является нежелание разбивать систему на части с описанными интерфейсами между ними. Использование ХП - возможно, не лучший (не самый понятный) интерфейс между БД и апп-сервером, но может быть с успехом заменен на те же вью с триггерами, внутри которых - те же ХП. Тогда и любимые всеми (но по-разному:) ) ОРМы думают, что работают с БД, и разработчик БД в своей части делает все, что считает нужным.

KachalovP.S. про масштабирование и кластеризацию в контексте ХП что-то никто не хочет опонировать :) Вопросы типа: "сколько стоит кластеризуемая БД?" явно оказались неудобными Не смешите людей - кластеризация апп-серевера, распараллеливающия обработку логики и кластеризациция БД, распараллеливающия обработку сверхбольших массивов данных - это совершенно разные (и не сключающе друг друга) задачи, противопоставлять их нельзя. И если появилась нечастая необходимость кластеризации именно БД, то стоимость СУБД будет очень небольшим довеском к стоимости железа.

Еще раз не о "плюсах", а о необходимости логики в БД:
1. Все, что можно сделать на чистом SQL - надо на нем и делать, процедурная обработка данных - зло . Параллелизм внутри запроса не может заменить никакая процедура, где бы она не находилась, как и оптимизацию этого запроса на основании актуальных данных (статистики).
Естественно, писать многостраничные запросы, как и следить за целостностью модели в БД может только специалист в конкретной СУБД, эту БД проектирующий, и выносить все это за рамки БД - бред. Эту логику надо маскировать для использования в следующих уровнях обработки (апп-сервер, например) с помощью вью и/или ХП (в зависимости от СУБД), формируя для этих уровней интерфейс к БД.
2. Все, что нельзя сделать декларативно, но что касается только и именно обработки в рамках реляционной модели - лучше делать внутри БД, она это сделает гораздо эффективнее. Что, опять-таки, позволит разделить логические уровни при проектировании.
3. Внешние отн. реляционной модели задачи естественно могут (и как правило должны) решаться вне СУБД, на следующих уровнях.

P.S. С моей точки зрения - данный спор ни о чем, каждый инструмент должен решать свойственные именно ему задачи. И раскидать задачи проекта по соответствующим инструментам есть прямая обязанность проектировщика системы.
P.P.S. А ХП именно вместо запросов (а не вместе с ними), т.е. замена декларативного SQL на процедурную обработку - зло безусловное.