I wouldn't say a DAO layer with Hibernate is of great usefulness. What I would say is that a DAO layer is of great value.
Personally, I wouldn't create an application without the DAO layer as it abstracts any sort of persistence framework out of the logic in your application. The DAO can be altered in any manner, using different frameworks as and when required. You can swap DAO layers in and out of your application.
Let's say for instance you have a database with a Person table. Using IDE wizards, you can create hibernate objects, annotations, mapping files etc. There would be a hibernate Person object. Now as soon as your logic code starts making calls using the hibernate sessions to save and retrieve those Person objects, you have tied your application to Hibernate. What if hibernate ends up being deprecated and becoming fully incorporated into the EJB3 container. It means there would be no further support or maintenance of hibernate. In order to alter your code, you need to go through all of your logic and change all of your hibernate calls.
If you had a DAO layer in between your hibernate objects, and it is the DAO layer using the hibernate sessions, then your logic layer is completely protected from any ORM framework. You can create a completely new DAO layer if you wish, using something other than hibernate. And if you are coding properly, your DAO classes should be implementing interfaces, such that your logic code only knows about interfaces. And if you are incorporating Hibernate with Spring, then it is easier again to alter and inject new DAO classes into your logic code.
[ June 03, 2008: Message edited by: Matt Gaunt ]