Possibly the greatest benefit of a well-implemented ORM tool (like Hibernate) is caching. You can write the SQL, use a JDBC framework to ease the use of straight JDBC, and be more or less with a good ORM, but you can't beat cached objects.
Database transparency is a big hit too, but most (?) projects don't need it or don't care about it.
A big disadvantage of "straight" JDBC is that you need to write about 25 lines of "plumbing code" (managing resources and catching exceptions and whatnot) for every simple database hit you make.
Hibernate, as one example, mostly eliminates this.
Not having to write SQL is a "false advantage" of ORM, IMO. You still need to thoroughly understand the generated SQL, and as you seem to be experiencing,
it's just as challenging to declare mappings in XML as it is to learn SQL. It's just as bad to litter your code with HQL, or OQL, or JSQL, or whatever query language, as littering it with SQL. The answer, for whatever your chosen query language, is separating database queries into a data access layer.
JDO is more than an ORM specification as it also intends to handle all data persistence mechanisms, not just relational tables. This makes it more complicated than necessary if you only use relational database persistence.
I've been happy with Hibernate so far, and although I'm still on the steep slope of the learning curve, I've been able to successfully leverage its advantages in production code.
There are no magic bullets. We can only ease one headache by gaining a different one.