Of course, There Ain't No Such Thing As A Free Lunch.  As with all design decisions, there are tradeoffs involved in implementing CQRS.  The first such tradeoff is in complexity - there are more moving parts in the system, resulting in more things that might go wrong, at least during the initial setup stage, and more knowledge (and time) required by staff to learn how this pattern works and architect the application appropriately.  Further, there is an underlying assumption that it is OK to tell the user the wrong thing some of the time.  For instance, using a CQRS architecture for an order processing system, as Amazon.com does, a customer order may be responded to with merely a "Thank you, your order has been received and is being processed" rather than an actual order confirmation.  The actual confirmation is sent later, via email, once Amazon determines the item is in stock, the payment was properly processed, etc.  If for some reason there is a problem with the order, then a different notification needs to be sent to the customer, who by now has probably left Amazon's site and is no longer involved in the transaction.  If this is a rare exception, and if customers are OK with these kinds of things occurring from time to time, then this tradeoff is likely very acceptable.  However, if the application absolutely must provide an immediate, accurate answer to the user, then this kind of "I'm working on it and will let you know later" approach may not be appropriate.