This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I'd say no. Hibernate can support Stored Procedures but Stored Procedures are implicitly database dependent (since thats where they live) so putting an ORM in front of them doesn't make a great deal of sense. That is unless your evental goal is to make your application portable and slowly phase out the SPs?
Hibernate wont be a great disadvantage in this case. All you are doing is replacing one type of boiler plate code (JDBC) with another (Hibenrate) to no great imediate benefit.
I'll take the opposite opinion from Paul, simply from the fact that if you have Stored Procedures without Hibernate, you will have lots of JDBC code that translates the return results from stored procedures into your Java classes, which I always find error prone and harder to maintain.
That said, there is still lots of merit to Paul's post. For instance, there are lots of ways to get better performance out of Hibernate than through a stored procedure with Caching. And I find that an all SP solution is not flexible, maintainable, and leaves you vendor locked as Paul has said.
Personally, in today's technology, those people that fight for an all SP solution are out of date.