Data Access Objects (DAOs) are a common design pattern, and recommended by Sun. But the earliest examples of Java DAOs interacted directly with relational databases -- they were
I believe most DAOs are added by people for histerical (historical ;] ) reasons. You are right in that they were intially meant as a convenient encapsulation of the SQL glue required to perform the CRUD operations in pre ORM days. Nowadays, with transparent persistence, their role is now largely redundant.
What is now appropriate is the concepts of Repositories and Services:
Repository: A class that stores a collection of query methods implemented in ORM specific code (eg, Hibernate or JDO)
Typically you can create an abstract base class Repository and then provide an ORM specific implementation into which you implement all the query methods in code that is specific to your ORM. The great thing about this approach is that you can create a MockRepository implemenation to help test your app without using the DB.
Service: A class that stores a collection of methods that can orchestrate non trivial changes/additions to the object model (typically ORM independent code).
This helps to keep your app largely ORM independent - to port the app to another ORM really only involves the implementation of a new ORM specific Repository class(es).