It’s true that Ash does not enforce you to a specific architecture, one could definitely use Ash along with CQRS by for example have the Ash resources being constructed through the projections (effectively the “read-only” state that must only be updated as a result of an event being handled).
But the main point here is that using ES is a shift in mindset on how we approach solving business problems with software. My argument is that if one uses Ash as the main library to drive their modeling decisions they will likely be limited in the modeling they will end up doing. As @yordisprieto mentioned there are some core concepts of ES that in Ash exist through resources. For example one could easily make a projection as a standalone GenServer or whatnot, but they would have to insert the events as actions that belong to a Resource, so you already have to have a Resource to emit an event. It makes Resources as the core concept instead of Events.
The question I would ask is can you emit an event without needing a specific resource? If yes you can model ES effectively, if not you are constrained by resource oriented architecture (in effect even though Ash itself does not enforce an architecture, developers can build their architecture around Ash resources).
That being said, I think you can have ES and Ash separately in the same application (ES managing Events and Ash being the Application state) , Ash is indeed a really good abstraction around modeling resource oriented state, and at the end of the day even in ES software the “read-only” (updated only as a result of an event) state is usually resource oriented.
Finally something that is often misunderstood is that ES will be the dominant architecture in an application. That’s not necessary or effective, usually you only want to use ES on a subset of the core domain problems and most of your application can just use whatever other architecture is most convenient to you.
