CouchDB is great. It runs on Erlang VM (great for all the new Elixir developers). It has SpiderMonkey (Mozilla's JavaScript interpreter built in). It runs everywhere where Erlang can be installed (Windows, Linux, Mac, BSD, Solaris, Raspberry Pi)
Its data model has pre-defined attributes like _id and _rev. On saving a new document _id and _rev are generated automatically. On saving a new version of an existing document, _rev is checked automatically to detect revision mismatches. You can then ask for the current remote document, compare each value and ask the user what values to keep/replace. Can it be easier for users to merge data? Replications are also relatively easy.
With PouchDB, another open source project exists which can synchronize data between mobile and CouchDB cluster. Installing PouchDB on Node.js allows all kind of imaginable crazy setups.
CouchDB talks JSON over HTTP. You can use all kind of HTTP environments like proxies, firewalls, caches, etc. to build fantastic backends. npmjs.org runs on CouchDB cluster. That brings me to another great addition, CouchApps. Because of SpiderMonkey, you can write CouchApp inside your database. Think of it like Apache and PHP are running inside of MySQL but being powered by the best fault tolerance multi concurrent virtual machine called ErlangVM.
The drawback I guess is how you define data access. You need to create design documents that contain views, shows, lists, validations, lists and filters. Each of them written in JavaScript using a particular API. But every JavaScript developer knows how to read and write API's. The technical issue here is, that you force CouchDB to spawn multiple JavaScript engines (SpiderMonkey) on each saving of design documents. Each JavaScript engine will try to take a CPU core exclusively to compile your design documents code into binary code. This isn't a big deal on smaller projects but on mid-sized projects it can cause headaches, finding performance issues. Is it an environmental issue or conceptual problem in my design document? Bringing development code to production will cause massive saving of new/updated design documents. You need to plan which node in a CouchDB cluster you need to take 'offline' by not sending any query but instead pushing your code.
Until RethinkDB, I loved CouchDB pretty much. If CouchDB 2.0 will be released this year, things may change again, but right now RethinkDB behaves a bit more like what I expect even though it's not running on ErlangVM :-P
Couchbase isn't that great in my opinion. CouchDB+Membase sounds fast but rather sooner than later you are ending up with a pricing request process because for a Sync Gateway you need to pay. That what PouchDB and CouchDB to for free needs to be paid in Couchbase. Yes indeed, it's not trivial to talk to caches (Membase) but why should I ever cache DB responses when data can change over time? Most of the time dealing with caching issues forces you to call for support but it often looks like some other kind of an issue. Also, the sales guys can be very aggressive calling after you to make you sign a contract - but that is not technical, and maybe it was/is only my experience.
To sum it up. CouchDB is great. If ErlangVM isn't a problem to have it as additional dependency then you are getting a great JSON document-oriented database. The data model is easy but the data access design can be a bit confusing. Building clusters spread across the globe or company network is relatively easy. For all kind of programming languages, clients exist (in JavaScript land: I love nano while other may choose cradle).