I’ll try to leave most of the talking to other Ash users who see your message 
With that said, there are tons of escape hatches at various levels, from adding functional hooks to changes, to making actions manual and taking over their execution. One thing we’re actively working on(because it can be problematic) is making errors more understandable. More often than I would like, errors are lacking important context that would make debugging much easier. I don’t think this is a problem with the pattern, just something that requires some elbow grease on our end See: improvement: add error context to error creation / normalisation by rellen · Pull Request #440 · ash-project/ash · GitHub
In terms of performance, Ash generally leans into other tools to provide performance/stability guarantees, i.e AshPostgres ultimately runs your queries with Ecto. AshJsonApi is built with Plug, and AshGraphql uses Absinthe and Dataloader. I’d be lying if I said there was no additional overhead on top of those tools when using Ash, but similar to the error situation above, that isn’t intrinsic to what we’re doing, just optimizations waiting to be made
Check out AshHq if you haven’t already, its all implemented with Ash, from an extension that runs full text search with postgres, to the newly added (yesterday) AshBlog data layer that stores files in the priv directory. Lots of goodies in that codebase.
Site: https://ash-hq.org
Source: GitHub - ash-project/ash_hq: The Ash Framework homepage and documentation site. · GitHub
