I used to do a lot of consulting on how to use OODBMS tools and I've built my share of systems using them. They suffer from several problems starting with:

1) The source code defines your schema.

You write your object model, then start storing objects into the database. Great. Until you change the object model. Now you've got a nasty binary format compatibility problem and the schema migration tools all sucked eggs and frequently required taking the database offline for the migration to occur.

2) Locking granularity is too coarse for multiple users.

Where RDBMS systems allow table or row locking (like class or object locking), the OODBMS uses memory page locking which can cause lots of spurious locks that may interfere with competing transactions.

3) Death by a million patches.

OODBMS venders were constantly tweaking the binary file format which resulted in needing to time consuming conversion utilities with every update. Typically the conversion utilities required taking the database offline for as much as a couple hours.

It seems that by aiming at the embedded market they avoid these problems because there aren't going to be any updates or modifications to any of the software once its developed and it doesn't have to remain high availability. Plus there's likely only one user. And consider that most embedded devices have a single user and not too much storage - which begs the question of why bother with a database when non-volatile memory is likely available?