In CouchDB, unlike in MySQL, you come to understand what a join actually is - when it happens and what it costs performance wise.
What I like about CouchDB is that it's composed of a relatively small number of concepts. The more I code the more I prefer tools & libraries that utilize only a small number of concepts- the complexity, if it exists, is safely quarantined into the non-reusable application portion of the code and not in the tools I used to build it.
One can easily estimate the cost of a query in a relational database via EXPLAIN.
What relational databases do is decouple such implementation details from semantics, enabling higher levels of abstraction and therefore reasoning. Similarly, I'm happy to abstract the low-levels details of dictionaries in Python and not code my own hash table from scratch, or to use a compiler and not write assembly language. And while there are inevitable corner cases where hand-coded logic will outperform what a system can guess, handicapping yourself for a few extra cycles is something routinely (and rightly) derided in most programming circles.
Nobody debates that NoSQL systems are great for hand-tuning corner cases like these. It's the idea that they are a viable alternative to the relational model that is so objectionable, as it's a step backwards in abstraction.
What I like about CouchDB is that it's composed of a relatively small number of concepts. The more I code the more I prefer tools & libraries that utilize only a small number of concepts- the complexity, if it exists, is safely quarantined into the non-reusable application portion of the code and not in the tools I used to build it.