Why aren't OODBMS as widespread as RDBMS?

One reason that RDBMS has retained popularity is that it's established technology, well understood and has a standard language (SQL) that multiple vendors support. It also has a few good interfaces like ODBC and JDBC that make it connect with different languages pretty well. A stable API is a strong factor in keeping a technology dominant.

By contrast, there is no clear model for OODBMS, nor is there a standard language, nor is there a standard API. There's not even a de facto standard by having a leading vendor implementation.

The OODBMS concept might perform better than RDBMS+ORM. It depends entirely on the implementation. But it's also true that OODBMS don't solve the same set of problems that RDBMS are good at solving. Some data management tasks are much easier if you have referential integrity and relational headers enforced by the data management solution. These features are absent in the OODBMS model (at least so far).

There's a lot of noise on blogs that relational databases are obsolete, but RDBMS are nevertheless the best general-purpose solution for a great majority of data management tasks.

The biggest problem I've seen is lack of standardization. In the RDBMS world, you can get pretty far with any random database if you know SQL. They basically all implement it, with minor variations. I don't know a single existing RDBMS that doesn't do SQL: you can almost use "RDBMS" and "SQL" interchangeably.

The closest thing for an OODBMS is perhaps OQL, which has been an utter failure.

No database has ever implemented very much of it. I used a pretty nice commercial OODBMS a couple years ago, but (as of 2007 or so, and it was on major version 8 or 9) it didn't even support querying for an object by its name. The manual said simply that this part of OQL they hadn't gotten around to yet. (I'm not sure, but you might have been able to drop down into a native call to do that.)

Most object databases I've seen recently have native language interfaces rather than a query language like OQL. The system I used, for example, supported (only!) Perl and VB, IIRC. Limiting your audience to only a couple languages (or forcing them to write wrappers, as we did) is not the way to win friends.

Because of this, there's no competition, and therefore no easy backup plan. If you put your data in MS-SQL and Microsoft stopped supporting it, you can probably dump your data into Postgres and port your queries, without too much trouble. (It might be a lot of work, if you have a lot of queries, but I don't doubt you could do it. It's a pain, but not technically challenging.) Or Oracle, or MySQL, or many others, both commercial and free.

No such thing exists with an OODBMS: if the one you're using goes belly-up, or they take it in a direction that's not useful to you, or you find it lacks a key feature you need, you can't just dump your data into a competing OODBMS and port your queries. Instead, you're talking about changing a core library and making massive architecture changes. So realistically, you're limited to a commercial OODBMS who you really trust (can you name even one?), or an open-source OODBMS which you trust your team to maintain when things go bad.

If this sounds like FUD, sorry, I didn't intend that. But I've been there, and from a project management perspective I'd hesitate to go back, even though the programming environment can be wonderful. Another way to think of it is: look at how popular functional programming is today, despite what a good idea it is. OODBMS are like that, but worse, since it's not just your code, but your code and your data. I'd gladly start a major project in Erlang today, but I'd still hesitate to use an OODBMS.

OODBMS vendors: to change this, you need to make it easy to leave you for your competitors. You could dig up OQL and actually implement that, or do it at the API level like ODBC, or whatever. Even a standard dump format (using JSON?), and tools for import/export to/from that for several OODBMSs, would be a great start.

Data often lives longer and is more important than program. So even if you start a greenfield development today you have to consider the overall picture. There are more tools, processes and experienced people working with RDBM systems. Think beyond the program, how about capacity planning, data mining, reporting, ETL, integration with other data sources etc. How about your company acquiring another company and thus bringing all their relational data in your program. RDBMS and associated tools are so entrenched, proven and powerful that I don't there is any strategic sense in using anything else. In some small niche maybe but not in general.