EDUARD SAPOTSKI,

Вы просто не умеете готовить. SQL-код весьма трудоёмкий и объёмный по своей природе. Его лучше избегать всеми силами. А современные ORM умеют сами создавать базу под вашу модель.
Скажем, маппинг по соглашениям в последнем NHibernate позволяет замапить объектную модель на реляционную за пять строк кода (да, в реале чуть сложнее, но всё равно возможно). B еще одной строчкой создать эту базу с нуля, причём для любой из полутора десятков поддерживаемых СУБД.

Так скажите, дают ли вам рукописаные sql-ки такую гибкость?

Progaу меня требование от заказчика всё на хранимках, никакого доступа к таблицам.
Это не технический фактор. Плюсы ORM тут конечно меркнут.
Progaэто ты маленьким мальчикам рассказывай, а учетки, нормальные, логику держат на хранимках.
Вот примеры:
отчеты: 1 форма IFRS, оборотно-сальдовая ведомость, сходимость годового и месячного бюджетов.
операции: закрытие счетов
Посмотрел бы я на код на шарпе, очень интересно.

Да что рассказывать? Маленькие мальчики со временем становятся опытными, но остаются маленькими мальчиками.
Недавно искал работу, так ни одной конторы, которая бы писала модульные тесты не нашлось. И буквально на пальцах одной руки пересчитать кто пробовал отличные от предложенных мелкософтом фреймворки.
А писать на процедурах - это доступно и понятно программисту средней квалификации. Вот и получилось большая куча "нормальных" учёток.

Вестникс вставками и обновлениями могут быть концептуальные проблемы (пуристам могут не понравится одиночные вставки/обновления), но практические прогоны показывают, что на объемах вставок/обновлений до 100к все работает нормально, суммарно намного быстрее, чем все на процедурах(сбор данных для одного из отчётов на трёх страницах по одному заказу занимал 15 минут.

У меня два возражения:
1. Приличные ORM в силах производить пакетные вставки и обновления, а NHibernate таки может генерировать DML-запросы без загрузки сущностей на клиента.
2. На sql всё-таки можно сделать быстрее. Вопрос в цене вопроса.