The basic problem here is that people who design object models and people who design relational database models are working from different levels of granularity and see the world in fundamentally different ways. The reason that relational databases and the SQL language continue to dominate is because they work best with sets of data, not individual records. This is why the first wave of object-oriented databases failed; everything works great until you load it up with millions of objects, and then it grinds to a halt.
In those cases where it is appropriate to work with individual objects or database records, JDO should be fine. If the project is dealing with large data sets, however, there will be times where SQL will need to be utilized in order for the project to succeed. An experienced app designer should anticipate this need and show the developers how to recognize situations where set manipulation is appropriate. If you prototype your system using JDO and cross your fingers that everything will be fine when you go to production, you may be in for a nasty surprise.
Someday, we will sit around laughing about the days when we had mechanical hard drives instead of electronic storage with near-instantaneous data retrieval. Until that time, we will need to rely on the power of SQL to do the heavy hauling.