If your use case can't handle eventually consistent data or you have no way to successfully resolve conflicts/never cause conflicts then this product is not for you.

They've chosen availability over consistency, so when the network between your DB servers partitions your applications will still function. But partition A won't see what's happening on partition B and vice versa and when the partition heals you might have conflicts to resolve.

One great use case I can think of for this is a case where you have geographically clustered clients that need to read globally but only write locally. As long as you model your data correctly you could set up a master in each region so that your writes were fully ACID compliant then have the masters replicate to each other so that data from other regions was available for reading. You'd get the benefit of distributed writes, your local clusters could continue working even if there was a partition or one of the other clusters went down, and you'd assure yourself that you wouldn't have conflicts.