Hibernate vs JDBC

JDBC изначально содержит совсем небольшое количество кубиков-понятий для работы с базами данных, что делает его простым в использовании инструментом и в тоже время достаточно гибким оставаясь понятным. Hibernate и прочие ORM (включая JPA) - это в некотором роде макро-абстракция над JDBC. Изначально кажется, что ORM позволяет абстрагироваться от синтаксиса конкретной базы данных и упростить запросы, сократить процесс переноса данных из запроса в домэйн обьекты. Но чем больше я работаю с ORM тем больше понимаю, что абстракция от базы данных на практике мало нужна, разве в простых приложениях. А простота маппинга достигается за счет оверхеадов при работе, сложности с маханизмами каскадирования, дэтачмента обьектов, майнтененсом сессии и в конце-концов выясняется, что временя потраченное на поиск причины сообщения о проблемы с транзиентными записями, попытке приаттачить обьект внутри сессии, с валидацией полей, проблемами ленивой подгрузки обьектов и прочих проблем.. это время равносильно, а то и больше времени которое было бы потрачено на разработку с JDBC + портирование приложения на новую базу (с учетом, что изначально в коде используется шаблон проектирования DAO). ORM привносит обилие новых понятий, сущностей и рычагов, добавляет mutual состояния (а мы знаем, что чем меньше в приложении мутирующих перменных/состояний, тем более стабильно приложении (именно по этому фнкц-языки рулят)), что очевидным образом вытекает во все что я описал в предыдущем предложении. Есть ли смысл?
Есть такой фреймворк iBatis. Судя по названию сначала кажется, что делали его славяни (особенно с учетом н овости на главной странице "Abator Renamed to iBATOR"). Но вот заяление "iBATIS couples objects with stored procedures or SQL statements using a XML descriptor. Simplicity is the biggest advantage of the iBATIS Data Mapper over object relational mapping tools." притягивает. И вообще как оказалось замечательный фрэймворк!