The reason to use an ORM instead of an object database is twofold. One, it's safer to use a working database and put some libraries on top of it than it is to write your own database. Do you want to write unit tests for the deadlock detection algorithm? Two, sometimes you're writing an online transaction processing application (99% of web applications) with fixed domain objects, but you want the flexibility to slice-and-dice the data in the future. In that case, an ORM makes your relational database look like an object store to the application (which is exactly what it wants), but it also lets you play with the data in Excel if you want to. The key is not that the data is relational, but that it's in a standard format that other software understands.
Ultimately, there are three kinds of applications that you can write. One is what most software is; the user interacts with the application and generates state along the way and you want to record that state and act upon it. In that case, an object database is perfect; the state is meaningless without the application, so there's no reason to encode the state so as to be meaningful to other applications. The next case is something like this but where the data might be useful outside the application (auditing, reporting, other features). In that case, ORM is exactly what you need. Your application wants objects, but the other things that need the data want it in a database. So you compromise and store it in a database, using an ORM to make the relational database look like an object store to your application. The third case is an application that is not particularly interactive (think credit-card processing network), and you don't need any app-specific state to be preserved. In that case, raw database access is perfect; if all you are doing is INSERT INTO transactions VALUES ('jrockway', 'amazon.com', '19.95'), the ORM is just going to waste your time.