Não sei mas se você tem objetos grandes pra montar e usa ORM, não vai ter que rodar N queries separadas, ao invés de 1 query complicada que retorna tudo?
Se as queries rodam no banco, provavelmente em outra máquina, é uma viagem ao banco pra cada query. Isso pode afetar a performance da sua aplicação.
Sua aplicação já começa levantando um pesado objeto “SessionFactory” que fica a vida toda na memória de cada aplicação que use Hibernate na empresa. A cada requisição entra em cena o cache do hibernate consumindo mais memória, que apesar de poder ser desligado, maioria usa pra aproveitar os recursos da ferramenta, como por exemplo o perigoso lazy loading. Fazer querys complexas e performáticas na linguagem de objeto do Hibernate é muito mais complicado do que diretamente em SQL nativo. Pra evitar o problema de N querys vai ter que ser expert no confuso Criteria ou HQL. Como fuga dentro do próprio Hibernate acaba sendo melhor mapear SQL nativo, que fica mais prático e natural da fonte de dados relacional, é o que faço quando trabalho com sistema mantido em Hibernate. Hibernate costuma ser mais útil em sistemas que realmente precisam ser multi banco, onde justifica mais o gasto de seus recursos.
Cache do hibernate é inútil se os dados são atualizados com freqüência.
Problema é que muitos usam session com cache só pra poder usar o lazy loading, que é um perigo pra performance, gerando N querys. Desperdício de recurso.
Esse é o problema dos banco de dados “atualizáveis”. Não dá pra fazer uso de cache nas aplicações, por isso N queries é considerado um problema.
Pra todo programador que acaba tendo que lidar com otimização de query em vez de ux, e em especial para o cliente que está pagando para alguém que deveria estar agregando valor, lamento pelo desperdício de vocês.