taproot – Why hasn’t Graftroot been part of the covenant soft fork discussion thus far? What are the downsides to this proposal?

I haven’t heard much about Graftroot in the context of the covenant/vault discussion since around the time the Taproot soft fork was being finalized. The idea was initially posted on the bitcoin-dev mailing list in 2018 by Greg Maxwell. (An approachable explainer from Aaron van Wirdum is here.)

David Harding recently posted an idea on using Graftroot for vault recovery paths on X:

Wouldn’t a graftroot-like thing be a better solution? E..g, pay to a primary musig keypath with a scriptpath option for a 1 year CLTV for a secondary musig with a smaller set of signers. As 1 year approaches, delegate (offchain) to a 2 year CLTV for a new secondary musig with different keys. Have all of the secondary musig signers for the 1 year CLTV destroy their private keys for it. If at least one of them complies, the original 1 year CLTV is no longer accessible and the 2 year CLTV will become spendable in a year from present. Repeat each year.

Advantages: privacy and efficiency of taproot keypath spends in the normal case, more efficient onchain than an equivalent BIP345 vault in the recovery case, and arbitrary changes to the scriptpath options can be made offchain any time the primary musig keypath signers are available.

Are there any concrete reasons why Graftroot hasn’t been part of the covenant/vault discussion thus far? Just easier to design and reason about basic, limited opcodes? I did find a discussion on the bitcoin-dev mailing list discussing the complexity of Graftroot but that seems to be a critique of Taproot as much as a critique of Graftroot.