On the other hand the join-element allows it to map an object that crosses multiple tables. We did that a lot, because we had objects with some properties being subject to auditing and some properties being not. So we split up the object in one table with additional auditing information and one table without. We created a view (leaving out the auditing information) for the first table and some instead-of-triggers to make the view look and feel like a table. In the class-mapping, we sat dynamic-update and dynamic-insert to true. That in turn makes sure, that the view or the join-table only get updated if their respective properties were changed.
In SQL you end up writing a lot of joins when you query those objects. In HQL you look at objects, hence Hibernate writes the joins for you.
As to provide for later optimization we put all our queries into the mapping files. By doing so we could replace HQL-queries transparently with SQL-queries optimized for the RDBMS in use.
The only thing we stumbled upon was locking. If you lock such an object only the record in the master table gets locked rather than all the records in all the tables belonging to the object.

If you want to write your own SQL and populate existing Java objects from columns in the ResultSet, I think you’re looking for iBATIS.