Здравствуйте, Cyberax, Вы писали:

C>Масло масляное какое-то. ORM и так является persistance-слоем.

Не. ORM является библиотекой для построения persistance-слоя.

Б>>- отвязывает приложение от схемы БД (схема БД меняется часто)
C>Этим должна заниматься ORM и само приложение.

Приложение и занимается. Этот код лежит в persistance слое.
Чтобы не пришлось при небольших изменениях схемы выискивать по всему приложению запросы, которые нужно поменять.

Б>>- устраняет дублирование запросов, созданных с помощью ORM
C>???

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

Б>>- позволяет добавить SQL запросы в обход ORM
C>???

Это когда надо написать запрос на голом SQL. Где такой код хранить, как не в внутри persistance?

Б>>- позволяет добавить кеширование и делать другие оптимизации
C>Кэширование редко является полезным на уровне persistance.

Разные ситуации могут быть

C>В документе речь идёт об адаптерах — это таки технический термин. Означающий, что интерфейс ORM будет адаптироваться к внутреннему интерфейсу системы. От этого и возникает вопрос: нафига?

Этот адаптер — часть приложения, которая отвечает за persistance (т.е. persistance-слой). Реализует интерфейс persistance, а ORM — деталь реализации.
В некотором роде ORM адаптируется под интерфейс persistance, под требования приложения. Хотя, аддаптер может и не совсем подходящий термин.

С другой стороны, и persistance тоже не совсем слой (в "старом" понимании). Есть же и другие "слои" в инфраструктуре — слой поиска, слой нотификации, слой интеграции с какой-нибудь внешней системой и т.п.