I'm not sure I agree that ORMs are a code smell. I've used NHibernate (the C# equivalent to Hibernate) and more recently, Django ORM, both extensively. It's possible to get out the SQL generated by each, and 80% of the time, it's roughly what I'd write if I were writing SQL, and performs comparably.
The other 20% of the time there are performance differences, but only about half of those are big enough and in hot enough spots to warrant fixing. For those cases, some of them can be fixed by doing things a bit differently in the ORM, but often it's easiest to dip out of the ORM and write a little SQL. The mistake I see people making here is "fighting with the tools": if you find yourself fighting the ORM, just dip into SQL: the ORM doesn't make this hard to do.
What emerges from this strategy is that the ORM handles all your trivial cases, while you dip into SQL for your more complex queries.
It doesn't have to be all-or-nothing. The ORM can co-exist peacefully with a little SQL. If I had to choose "everything ORM" or "everything SQL", I'd certainly choose the latter, but we have other options.
All-SQL has its own problems. As your number of queries grows, you start to find duplication between parts of the code that moves tabular data into more user-palatable object forms. If you create abstractions to remove that duplication... slowly a half-baked in-house ORM emerges. Some projects aren't large enough or long-running enough for that to happen, but it isn't usually the small, short-term projects which have non-trivial datasets that ORM's can't handle.
Some of our differing ORM experiences might come from the different ORMs: maybe Hibernate is just bad and you'd have had a better time with one of the ORMs I've used. I wouldn't know as I haven't used Hibernate.