To be honest, I don't think this is the strongest argument for CTV. The hard part is not designing something that works, the hard part is getting custodians to adopt it. Can you imagine Coinbase putting significant resources into a system for users to mass exit? The ETFs are legally (and quite exceptionally!) forbidden from offering in-kind redemption. Corporate bitcoin vehicles will just bend the knee. There isn't even a presumption that MSTR holders can ever redeem the bitcoin underpinning that asset.
I expect congestion will eventually motivate custodians to level up to CTV fanouts, unless some disaster happens to precipitate its development.
Good bitcoin custodians might be motivated to build and deploy something. In an emergency they would contact their users and instruct them how to perform a withdrawal transaction. The hard part here will be getting all their users on a non-custodial wallet. It can be done. The lightning community is a shining example of how to build guerilla educational communities. I would start by chatting with D++.
In the coinbase playground I designed the best possible UX for pool withdrawals. It adheres to standard mempool policy rules so you can just broadcast it to the network and you're done. It fits max 319 outputs, carries the minimum accepted fee, and has an anchor output so that anyone can fee bump it. Users don't need to do anything and it will eventually confirm. They have the option to accelerate confirmation and don't need to store any offchain data.
I made this to be a straight-forward upgrade for Ocean payouts. You could modify the design and replace a few of those outputs with more CTV transactions. This lets you build a tree of arbitrary depth and breadth. You'd have to be careful about resource starvation at the deepest leaves of the tree since they will confirm last. You could do something as simple as paying higher fees in transactions closer to the root of the tree. This also lets you stratify your payouts in order of priority. If the user pays a higher fee their money becomes spendable sooner. If they don't pay extra they wait longer.
This is a really ergonomic and simple design because it externalizes the transaction data to the mempool. This is probably fine for most people. It will look like the inscription craze all over again. The mempool will fill up and fees will be persistently high for an extended period. Eventually it will clear.
Custodians should be prepared to back up user unroll transactions and provide them upon request. They probably won't need the backups but it would be negligent to delete this data.
Interestingly, these users will be forced HODLers for the duration of the on-chain congestion. Good. They will learn a valuable lesson and come out of the experience wealthier than they went in.