Great writeup, thanks!! I think the Python community could really benefit from the tools of DDD and following patterns like CQRS and the Clean Architecture / Onion Architecture / Hexagonal Architecture etc..
Some small bits of feedback / personal opinions:
Nitpick, but regarding the idea of using DTOs to extend the ORM class I'm not sure I live this naming as DTOs are traditionally thought of as dumb transport objects for data - for transferring objects between boundaries and absent of logic
I'd maybe refer to these as DAOs (Data Access Objects) as I believe this is the canonical term here. I am not a fan of DAOs, but generally okay with using them if an ORM is necessary and as long as strategies of DDD are applied to mitigate the potential problems of DAOs (by abstracting them behind a repository).
Regarding the Unit of Work pattern I think there is one other alternative, but the two are not mutually exclusive. Ideally your use cases, at least for your mutations, typically correlate with some operation on an entity or aggregate. This is the whole point of aggregate design - cohesion of things that must change together within a transaction. With good aggregate design I've found you can often avoid the UoW pattern except for exceptional cases (which any complex application will likely have). getting into more complex territory, but there are also sagas to consider for coordinating operations across aggregates (and service boundaries).