When you mention object databases, can you name any examples? As far as I know object databases where talked about a lot some years ago, but never really gained significant widespread adoption.
Also, the article makes the point that non-relational databases are not just about scalability. In fact, in the case of graph databases, scaling problems are just as pronounced as with relational databases. The different data models can enable you to make good database designs, even if the structure of your data is against you.
PostgreSQL HStore is very handy in situations such as this: http://www.postgresql.org/docs/8.3/static/hstore.html
Frequently you can avoid having object that have a wide variety of attributes most of which are empty in the first place. That often indicates that the objects are not of the same type and that that table should be broken into other tables of objects that are truly alike.
That, though, is not always the case. When you truly have that situation with objects of the same kind, then I do not see why allowing the numerous empty columns (as long as they are all bound to the key and only the key) or the "object-key-valuy" tables are bad relational designs. If I am missing something, please let me know.
As for the object databases, the only one I have really heard of is db4o as another posted mentioned. I do believe that they are used in some areas of physics though. I have never used them personally, but I have heard of people using them in small scale projects just as a way to avoid the object-relational impedence mismatch complications.
To your last paragraph, I agree completely. There is room and a place for both relational and non-relational databases.
It seems that db4o supports some pretty flexible query mechanisms. That leads me to worry about performance. One of my recurring nightmares of relational databases and SQL is optimizing queries on non-trivial constantly-evolving schemas, and I can't help wondering if db4o has the same horrors in store.
HOWEVER, my sense is that bringing a relational mindset to object databases is not going to realize the full potential of them; you have to think about storing the data elements differently.
Object databases seem great for OLTP apps. In particular, ones that require working with individual accounts/patient charts/etc, i.e. query a person's account, modify a data element, and save it back to the db. For something more analytical, like spotting trends in historical data, I'd prefer the full power of an RDBMS and the SQL language that goes with it.
All non-trivial problems change along the way.
Allow me to channel CJ Date and point out current popular databases are not truly relational. A proper relational database built around Tutorial D would pretty much always be the way to go, even if your problem is highly OO.
His list of "symptoms" that a relational database is not right for you are more often symptoms that your relational database was not well designed (or that the problem you were trying to solve changed along the way) rather than that the relational model itself does not fit your needs.
I think this applies to all his "structural symptoms" but especially with "Do you have tables with lots of columns, only a few of which are actually used by any particular row?" This is more often a sign that the database was not properly normalized than anything else.
This of course is not to say that the relational model is right for everything. In some cases, object oriented databases are the way to go and if you truly need a vast level of scalability and you can afford to relax the ACID standard then it makes sense to look at non-relational options.
There is room in the world for both relational and non-relational models, but I do not think fashion should play a role in choosing a technology personally.