I cannot imagine anything where it would make sense unless you're implementing an actual framework such as Spring in javaland.
And at that point I'd say you're wasting effort and just using spring boot should be preferable.
It does make sense with these super low level frameworks though, but which corporation makes them in-house at this point?
If your business is talking about updating/deleting/inserting data, you are not describing the actual reasoning behind the change. For DDD, it makes sense to figure out why exactly you are doing the things you do, and model these explicitly in your systems for those parts that matter.
The stereo-typical example for this is an address change: if you model this as an "AddressUpdated", you might as well use CRUD, as this does not specify the intent of the change.
You could change an address because it contained a typo, but you can also change it because someone moved. These might lead to different outcomes, so in DDD you would typically model these as "AddressTypoCorrected" and "ContactMoved".
There are other fine-grained aspects, for example the need of an identity for an object: physical money is considered a value object (so it has no specific ID per instance) in almost all contexts, unless you are the national bank: all of a sudden the identity (serial number of the bill) does matter, so the same "thing" might have different "models" within different parts of the business.
Other examples might be value objects for specific areas, for example weight. Typically weight starts out as a number, and all of a sudden there might be a need to add a precision, mark it as an estimate, or have it "unknown". In order to avoid if-statements all over the code, you construct a "weight value object" that properly manages all of these peculiarities in a single place (i.e. what's the result of an estimate+undefined etc.)
I'm sure there are successful and maintainable projects that utilize this design approach.
Nonetheless, the only thing I could think of after reading your example is just how many subtle bugs and inconsistent behaviors this engine will have with various edgecases, so I'm still pretty convinced I'd rather implement it with less abstraction/indirection.
It might just be a difference of character at the end of the day, because I do agree that what you write sounds great. I just see it more like a triangle in the CAP theorem, where the edges are speed, abstraction/extensibility and stability/consistency
This example clarifies the intent behind DDD: make the implicit explicit and make sure there is awareness about all the edge cases.
It might be as simple as contacting a user in case you have an uncovered edge case, but at least you'd be aware that your system is unable to handle edge case X. (In non-DDD scenarios this would just be a bug that emerges - implicit behavior.)
This line of reasoning cuts both ways: how many bugs and inconsistent behaviors often pop up because developers rushed to write code without gathering enough requirements on the domain, how many productivity problems are caused by growing the system by accretion where it can, and how many rewrites were required just to fit the system's domain to the problem and shed technical debt from the accretion.