зынет, упаси меня от olap и кубов.
Фигасе. А ну-ка расскажи, как ты по большим объемам отчеты снимаешь? По боевой базе? Или с большими объемами не работаешь?
зыкстати напиши мне без стороннего кода условие where с поиском по названию поля, переданному как аргумент, на linq
да ладно, можешь не писать, суть надеюсь понял. Задача стара как боян и существует с момента появления самого linq, и вроде как самой библиотекой она так и осталась нерешенной.
Что за детский сад, зы? DLINQ

зыбольшинство проектов, о которых я знаю, либо никогда не меняли базу, либо делали это исключительно ради оптимизации (например, переход с sql на nosql).
Речь не о "случайном" изменении базы, а о подобной возможности. Я учавствовал в проектах, в которых заложена поддержка различных БД (Oracle, MS SQL). И это круто. Как будешь решать такую задачу, дублировать дата-слой под каждую БД?

зыНельзя тупо поменять базу, ничего не поменять в коде и получить +500% в скорости.
Можно. И скорость тут не причем.

зыТак что ИМХО смена базы — проблема и, соответственно, выгода, сильно надуманы.
Это реальность, зы, с которой ты просто не сталкивался.

зыДа, ты сейчас скажешь что ORM позволит оставить бОльшую часть кода как есть, но тот же переход sql->nosql требует заодно и смены подхода к работе с данными.
И это тоже. SQL vs NOSQL - разные подходы, сомневаюсь, что такой переход возможен. Давай возьмем лучше Oracle и MSSQL, самые распространенные корпоративные сервера. Переход безболезненный. Без ORM это практически невозможно.

зыА количество кода, которое необходимо будет переписать, зависит не от факта использования ORM, а от наличия первоначальной абстракции DAL и BL.
Абстракция изначально заложена в движок ORM. Наличие провайдера даст возможность генерировать "свой" SQL. Вот и вся абстракция. По кол-ву таких абстракций (кол-во поддерживаемых СУБД) хибер - лидер.

зыВ хибере очень много всего, что нужно настроить, чтобы заработало. Более высокий порог вхождения.
Та я тебя умоляю, проще пареной репы :) Посложнее, конечно, чем L2S, но не до базрассудства.

зыА если внезапно начнет глючить в неумелых руках, то ошибки можно искать долго и упорно.
Зы, не аргумент. Неумелым рукам и мороженое противопоказано, подавится и умрет.

зыОсобенно коварны транзакции и кэш. В некоторых случаях кэш вообще нафиг не нужен, а он есть.
Зы, ну вот что ты фантазируешь, а? ;)

зыА если несколько серверов — появляется ещё и проблема репликации кэша.
Ты имеешь ввиду, если несколько нод в кластере. Так вот пишется либо свой балансировщик, либо вынос кеша на слой БД. Второе проще. Это как встроенная возможность хранения ASP.NET сессии в БД для такой кластерной архитектуры. Ничего сложного.

зыЯ не говорю что это отмазки ламеров чтобы не использовать. Пожалуйста, если это все нужно и умеешь работать. Но если нет — то хибер крайне избыточен и потери CPU внутри на все перделки при большой нагрузке становятся сильно заметны.
Если не умеешь водить - не садись, мне не нравятся такие аргументы. Хибер не сложен, верь мне.

зыНапример, мне нужно делать выборки актуальных данных по вроде бы простым динамическим критериям. Нужно делать очень быстро, много и на большом объеме данных. Хибер не в состоянии это закэшировать, просто нет таких алгоритмов. Он хорошо справляется с поиском по ключу, но сложнее — проходит мимо. Лучше взять инструмент проще и эффективнее, например mybatis, и получить то, что мне нужно, сразу и без танцев.
На больших наборах только OLAP поможет. Для поиска - полнотекст. Другого не дано. Какие размеры для тебя большие?
Для меня - несколько терабайт (разумеется, никаких блобов).

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