I think the difference here is that normal “expiry” proposals say “this transaction is invalid after X happens”, whereas this approach says “this spending path is invalid if this transaction was confirmed after X”.
I think it’s worth comparing this to a generic ability to introspect the confirmation height of the coin being spent; I proposed that in the OP_TX thread on bitcoindev 8 months or so ago.
Introspecting commit height gives you roughly the same functionality in a straightforward way, instead of (nSequence R + bit21, nLockTime H) write the script (<TXSEL_HEIGHT> OP_TX <H-100> LESSTHANOREQUAL VERIFY).
You can somewhat do parent height introspection with this feature, in that 100 CSV 900100 CLTV will verify that the parent was mined prior to block 900000, if nSequence bit 21 is also set.
I don’t see a strong argument for why the consensus-enforced minimum delay here should be 100 blocks rather than 50, 20, 10, 6 or even 1 – for coinbase outputs that makes some sense; coinbases pay directly to miners who are ultimately responsible for whether we see extensive reorgs or not, but for individual transactions, I don’t think this creates a significantly bigger risk in regards to reorgs than regular double-spends.