It's not requirements by "what to do" but the requirements of "what we need to make "what to do"" work. For example if you are going to add two numbers you have to use some sort of arithmetic to solve that problem, right? If you fail using arithmetic to solve it you will not solve the problem and your function will do something else. The requirement of solving in this particular case will be "use arithmetic".
So this means for your problem to be correct you have to use the correct tools to solve that problem. If you think that everything (all problems) can be decomposed to independent events, which per definition can happen in any order, you can safely use ES. But if they have any dependency on each other you need ordering, and ordering in a distributed system is a hard problem. And add to this is that somewhere some guy from the business will come up with an actual requirement where you must synchronize and if you then have solution which inherently where this is not possible you are screwed.
This is true for both reading and writing in that system. Most problems are dependent otherwise it won't solve/do anything, there are usually a purpose with most systems.
While you can have systems where the events are entirely independent, structurally independent, such as JS event loop and red/blue methods (just locally independent), or it doesn't matter like plain application logs, this is rarely, if not impossible between domains if you want a correct system since you won't know if all events have arrived yet to tigger another event, if there's any dependency between them, which there will be between two domains.
DDD is good but not in this context, CQRS is trying to partially to solve above problems, but not needed and is just bloating. It does fit better with C# since the (weird) implementation of async/await and potentially with JS for the same reasons. ES do have their use cases where they fit very well but not with the practical impacts of DDD.