Spring é popular porque cuida de todo código repetitivo de recortar e colar que você tem com qualquer estrutura ORM.
Pense em try ... finally blocks, lidando com o objeto de sessão (Hibernate ou outro) e commit / rollback (transações).
Isso você terá que repetir diversas vezes, tornando o código poluído e de difícil manutenção, propenso a erros.
O gerenciamento de transações também é talvez o grande carro chefe do Spring.
Você pode definir transações usando anotações ou no arquivo de configuração do Spring xml.
No arquivo de configuração, o benefício é que você pode usar curingas para especificar que, por exemplo,
todos os métodos de busca em alguns conjuntos de pacotes devem suportar transações (PROPAGATION_SUPPORTS),
mas todos os métodos insert, update, delete devem exigir transações (PROPAGATION_REQUIRED).
Então, eu sempre usaria o Spring, independentemente da estrutura do ORM.
Se você tiver requisitos simples ou não tanto código JDBC, os JDBC templates do Spring podem ser suficientes para você.
E, o Spring facilita a atualização para o Hibernate quando necessário.
Spring não tem um ORM próprio. Você pode usar o Hibernate, o TopLink, o iBatis ou o JDO.
Você está livre para usar o Spring JDBC, mas você tem que escrever todos os mappers por conta própria.
É aconselhável não usar ORM se você não gosta de SQL dinâmico ou da complexidade de uma solução ORM.
Você também pode eliminar uma dependência escolhendo a persistência por conta própria.
fontes:
https://stackoverflow.com/questions/3822551/spring-orm-or-hibernate