Я думаю что 1С-ка реализована так не из-за опасения того, что код куда-то уйдет. Хранимки в конце-концов и шифровать можно. Здесь проблема в другом. И 1С - это все-таки не образец хорошей архитектуры к сожалению, она до сих пор несет отпечаток файл-серверного прошлого в клиент-серверном варианте. Отлаживаемость и простота модификации ядра конечно никак не входит в их приоритеты, а вот простота написания/отладки/расширения функционала на основе ядра безусловно входит.

Я думаю, что разработчики прикладных решений на основе той же 1С просто застрелились/утопились/повесились бы, если бы им пришлось использовать ядро, написанное на хранимках, да еще и расширять его. Подумайте сами, почему.

Господа Один1, tygra, Old Nick и ASCRUS, вы все говорите правильно, но возражаете на те заявления, которых здесь не было. Разговор вообще о другом идет. Никто не спорит, что работа с множествами должна вестись на SQL-сервере. Где вы видели обратное утверждение - ткните пальцем пожалуйста... Речь идет о том, что эту бизнес-логику удобнее всего структурировать по ООП-принципам, что сделать в базе данных если и можно, о чем здесь говорил Old Nick, то честно говоря через одно место.
СУБД для этого не предназначена, так же как и ООП не предназначено для работы с множествами. Я не спорю, что сделать эмуляцию ООП на процедурном языке, предназначенном для работы с множествами можно, только зачем? Это будет криво и неудобно.

Для меня вопрос необходимости объектной прослойки для большинства задач, связанных с корпоративным ИС вообще не стоит. Вопрос в том, она должна располагаться на клиенте или на сервере приложений. Какие функции в моем случае выполняет сервер приложений (я говорю только о тех, которые реально используются, если говорить об абстрактных функциях, которые может выполнять сервер приложений, то их можно набрать на полстраницы):
Кэширование метаданных и определенных выборок, слой удаленного доступа (вебсервисы), своя реализация batch'ей, т.е. команды, генерирующие запросы, относящиеся к одному объекту, накапливаются и затем посылаются одним запросом, некоторая часть бизнес-логики, работающая с единичными объектами.

Я соглашусь - большая часть бизнес-логики реализуется именно в БД (не вся). Но клиент работает с этой бизнес-логикой через объектную прослойку, а не через запросы и рекордсеты. Сервер приложений в данном случае выполняет вспомогательные функции, но это все же не провайдер доступа к СУБД через интернет, не надо утрировать. Объектная прослойка - это ведь не просто обертка, через которую выполняются CRUD-операции над таблицей. Ее функции могут быть гораздо шире.

Я согласен, что есть задачи, для которых объектную прослойку можно размещать на клиенте, а то и вообще обойтись без нее. И не понимаю людей, которые с пеной у рта доказывают, что их подход единственно верный.

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