At a high level, I believe so! But there are some interesting details to expand on.
On my proposal there’s no need of a DSL exactly. The smart contract can use its own turing-complete language to build the description. Think of a read method (e.g. eth_call), implemented as a pure function, that receives the transaction itself and returns a description. It might be convenient to have a DSL, but it’s not necessary.
Furthermore, if the contract receives the message and its signature (say, a rollup receiving a list of EIP-712 messages plus signature), I believe we can even omit the “hash of the evaluated DSL”, because the smart contract can recover this hash. Let me give more details. Consider that the user signs the tuple (message, alleged description). They can omit the description, submitting to the blockchain the tuple (signature, message). The smart contract finally recovers the correct description, rebuilds the tuple (message, description), and verifies whether the signature matches.
But at a high level, I believe the differences you listed are correct, and the rest is implementation details.
I think another consideration is where these techniques would be used. In L1, I believe the added costs of my proposal may be prohibitive. I believe 719 has this advantage. But in L2/L3, specially app-specific ones (since the application has the entire blockspace for itself), the added cost could be minor.