Thinking in terms of CAP couchbase keeps consistency for each Document, as soon as the primary store for a certain document is not reachable the cluster will not accept writes for this document, and by doing so keeping the document consistent. If Couchbase would fokus on availability then there would be the need to deal with conflicts in case of a network partition as both sides of the partition could be written to. If you use XDCR this is a different story as 2 clusters can accept writes while XDCR is down and replicate those writes after the partition is no longer present. In this case you of course need to deal with conflicts at that time.
Couchbase choose the tradeoff off not being available in case of a network partition between the but providing the developer with consistent data. You can read more on this, and how this might be the right thing to do in a lot of cases in Damien Katz Blog.
Martin Fowler discusses the different scenarios in his talk Introduction to NoSQL