(click on the title to access full article on medium.com)
tl;dr limitations & pitfalls:

• Eventual Consistency : that queue between the write and read model can fill up
• Whole system fallacy : CQRS is not an architectural pattern and should not be applied to a whole system
• Task based UIs : they focus their design on the user intent.[...] your events will be based on a SomethingCreated or SomethingUpdated which has no business value at all. If the events are being designing like this then it is clear you’re not using DDD at all and you’re better of without event sourcing
• Event schema : managing these changes is one of the most complex and error prone drawbacks associated with event sourcing. A strategy should be prepared upfront and considered on the system design.
• Event granularity : have your commands and events reflecting the intent of the user staying true to DDD [...] it’s very easy to choose the wrong design.
• Operation flexibility : to undo an action means sending the command with the opposite action. It is harder to affect multiple entities and requires a knowledge of the system, not like SQL that everyone knows