В общем случае можно сказать что hibernate не дает выигрыша только на тривиальных приложениях.

см. http://hibernate.org/15.html

авторSo why don't you provide an "official" Hibernate benchmark?

Many people try to benchmark Hibernate. All public benchmarks we have seen so far had (and most still have) serious flaws.

The first category of benchmarks are trivial micro benchmarks. Hibernate of course will have an overhead in simple scenarios (loading 50.000 objects and doing nothing else is considered trivial) compared to JDBC. See this page for a critique of a trivial benchmark. If you'd like to avoid writing your own trivial and not very conclusive tests, have a look at the perftest target in Hibernate's build file. We use this target to check if a trivial performance bug slipped into the Hibernate code. You can use it to verify the JDBC overhead of Hibernate in trivial situations. But, as should be clear now, these numbers are meaningless for real application performance and scalability.

In a fair benchmark with complex data associations/joins, highly concurrent access, random updates of data in the application, real-world data set size, and utilizing other Hibernate features, you will find Hibernate perform very well. Why is there no such benchmark provided by the Hibernate developers? The first reason is trust. Why would you believe that the numbers shown by the vendor of a product, in a comparative benchmark, are true? The second reason is applicability. Certainly, a fair benchmark would show the benefits of Hibernate in a typical complete application with realistic concurrent access. However, the number of variables in any decent benchmark make it almost impossible to transfer these results into reasonable conclusions about the performance of your own application. Your application is different. (If you came here from a forum thread, think about it: instead of arguing with you about your trivial micro benchmark, we would be arguing why you don't see the same results in your application...) For these reasons we always recommend that you benchmark your application yourself. We encourage you to see performance and load testing as a natural stage in the life of your application - don't go into production with only micro benchmarks. Setting up benchmarks for your application and scenario, and helping you in this stage is in fact one of our usual support and consulting services.

значит в области orm дело сейчас обстоит так
было EJB версии < 3 и JDO. В EJB были такие EntityBean'ы, а JDO это была спецификация (т.е. это не продукт) на средства ORM в java по которой независимые поставщики делали свои продукты.

В настоящее время JDO и EntityBean переросли в EJB3, который вместо EntityBean'ов позволяет использовать pojo-объекты и больше похож именно на JDO.

Hibernate до 3 версии был самостоятельным средством ORM в java не соответсвовавшим JDO, в отличие например от Kodo. В 3й же версии он выполнили его интеграцию именно с EJB3

Какие ещё есть подходы в этой области?
Традиционно в java для работы с RDBMS есть JDBC, SQLJ, JDO, EntityBean'ы, Hibernate и т.д.

при этом от JDO, EntityBean'ы надо перехадить на EJB3 и в качестве Persistence Manager'а использовать Hibernate 3.

описание концепции
ORM