Yep this is a good example construction. I'd also point out that modulo a privacy improvement, you can also script it as something like:
IF IF <T> CLTV B DROP CHECKSIG ELSE <T2> CLTV DROP A CHECKSIG ENDIF ELSE 2 A B 2 CHECKMULTI ENDIF
This way you equivalently have cooperative closing / early closing positions, but you make the redeem script non-interactive to setup which enable someone to pay into one of these contracts without doing pre-signeds. This is unfortunate for privacy as the script is then visible, but in a taproot world it's fine.
Of course the non interactivity goes away if you want non-binary outcomes (e.g., Alice gets 1.5 Coin and Bob gets .5 Coin in case A, Bob gets 1.5 Coin Alice gets .5 coin in Case B).
And it's also possible to mix relative and absolute time locks for some added fun behavior (e.g., you win if > Time and > Blocks)
A while back I put together some python code which handles these embedded in basic channels between two parties (no routing). This enables you to high-frequency update and model a hashrate perpetual swap, assuming your counterparty is online.
The general issue with this construction family is that the contracts are metastable. E.g., if you're targeting a 100 block deficit , that means you have 100 blocks of time to claim the funds before either party can win. So there's some minimum times and hashrate moves to play with, and the less "clearly correct" you were, the less clearly correct the execution will be. This makes the channel version of the contract compelling as you can update and revoke frequently on further out contracts.