taproot – Why hasn’t Graftroot participated in Covenant soft fork discussions so far? What are the downsides to this proposal?

I haven’t heard much about Graftroot in the context of covenant/vault discussions since around the time the Taproot soft fork was finalized. This idea was first posted by Greg Maxwell to the Bitcoin development mailing list in 2018. (Aaron van Wirdum’s accessible explainer is here.)

David Harding recently posted an idea about using Graftroot as a vault recovery path in X.

Wouldn’t something like grafted roots be a better solution? For example, you pay for a primary music key path with a scripted path option for one year of CLTV for secondary music with fewer signers. As the year approaches, it is delegated (off-chain) to the two-year CLTV for new secondary music in a different key. 1 year Ensure that all secondary music signers on CLTV destroy their private keys. If you comply with any of them, your original one-year CLTV will no longer be available and your two-year CLTV will become available one year from now. Repeat every year.

Advantages: Privacy and efficiency of taproot key path spending in the general case, more efficient on-chain than an equivalent BIP345 store in the recovery case, arbitrary changes to script path options are off whenever the default music key path signer is available It can be done in a chain.

Is there a specific reason why Graftroot hasn’t participated in covenant/vault discussions thus far? Are basic, constrained opcodes easier to design and reason about? I found a discussion on the bitcoin-dev mailing list discussing the complexities of Graftroot, but it seems to be as much a criticism of Taproot as it is a criticism of Graftroot.