CouchDB's killer feature (not mentioned on the linked page) is of course, offline replication. So you can take a copy of the database with you, work in disconnected mode, and synchronize later. And this can be done with any number of users, all writing and synchronizing independently.
Here's a CouchApp that (with a non-demo dataset) we use internally for TODO management. I have a copy running on my laptop, on my MacMini at home, on the office server, in the cloud, and of course, on my Android phone. I synchronize them when I feel like it (but I could configure it to continuously synchronize in the background).
In CouchDB's document model this manifests itself as the challenge of of deciding how to split the results of user interactions across documents. Eg: don't store comments on the blog post document, keep them on their own documents, as they have different update patters. Of course this pattern doesn't answer everything, but it gets the vast middle of use cases.
I am using MongoDB for Cheméo[1]. It is a chemical component properties search engine. The document store is very nice as I can easily store in one document all the data related to a given component (all the properties, the source of the information, etc.).
I keep PostgreSQL for many things, but the "business related" data are stored in Mongo. This is running pretty well and it makes the agile part of the development easy, as one have nearly no impedance miss match between the code and the storage (the MongoDB drivers return ordered dictionaries and lists and I can access them from Python and PHP easily).
I was definitely faster from "idea to market" with Mongo.
True, I have run into these limits with CouchDB. Anyways this is a cool storage and I found workarounds like pre- and post filtering or multiple-step lookups.
oh yeah I love couchdb and document databases in general, it's a wonderful and fundamental tech... it's just a certain amount of effort to stuff a particular problem into a btree format, so sometimes it's easier to work with something like postgres
