I've been thinking about writing something about covenant proposals from the viewpoint of wallet vaults specifically (mostly because that's the use case I care most about).
CTV is basically the minimal covenant opcode you can do that doesn't have malleability. Everything else either introduces malleability, infinite recursion, or has interactions with other proposed opcodes that could introduce potentially undesirable effects like those.
TXHASH+CSFS seems like on its own might enable pretty much identical capabilities to CTV (including no malleability). But it can also do other things (mostly because CSFS can do other things), which isn't necessarily a bad thing, but its more stuff to be analyzed. TXHASH+CSFS in terms of wallet vaults seems to provide no benefits over CTV as far as I can imagine.
It seems pretty clear that anything involving OP_CAT is out for the time being. There are so many things it can enable that it seems most people aren't comfortable adding it at the moment.
APO wallet vaults seem rather hacky, inefficient, and limited. Certainly not easy to reason about. But this is somewhat a function of my limited understanding of them. Its not clear to me if anyone is actually suggesting that we should use APO for covenants, but it doesn't feel like the right approach.
TLUV + IN_OUT_AMOUNT can do infinitely recursive covenants. IN_OUT_AMOUNT wasn't very clearly specified that I know of, but its not a very robust way of ensuring the correct amount goes where you want. If TLUV requires a single input and a single output, IN_OUT_AMOUNT makes sense because you can simply do opcode math to determine if the output is receiving enough coins (and not eg being all lost as fees). Maybe it could be extended to allow multiple outputs, but extending it to allow for multiple inputs would be difficult and you'd probably want a completely different mechanism for that. If you're doing any math the script itself around amounts and fees, this doesn't work well in any scenario where multiple inputs might send to the same address, or be combined into the same output, since each input's script can't interact.
But since TLUV at its most basic should be able to say "remove the only tapleaf in this tree and replace it with this other tap tree", it should be able to do pretty arbitrary covenants. It ideally should be paired up with something that has better control over how input amounts flow to outputs than IN_OUT_AMOUNT allows (see the design considerations here).
TLUV is built for evictions, but it seems its likely not really very good at that, as Zman mentioned in
his post about OP_EVICT (which is a covenant opcode that can't be used for wallet vaults, tho perhaps its characteristics can be used in a kind of TLUV2 opcode that does evictions better, but also can add tapleaves).
OP_CHECKOUTPUTVERIFY is another interesting one. Also has a form that allows recursive covenants. It also has similar awkwardness as TLUV + IN_OUT_AMOUNT around multi-input transactions. It has the half-spend problem if two outputs are combined that specify the same output index and script pattern. It also seems like a rather expensive opcode to use beyond very simple covenants, since the scripts basically has to be duplicated in the transaction specifying the covenant and then again when the subsequent transaction is spent. Its not very taproot friendly either: would you have to specify the entire taproot script tree? Any similar opcode that requires specifying the exact script(s) fundamentally can't take advantage taproot's ability to keep scripts private until that spend path is actually used.
As far as I can tell, few of these other covenant opcodes have even been concretely specified, let alone analyzed enough to know whether they're worth pursuing. It seems like all but CTV (potentially TXHASH+CSFS) have significant flaws and would need reworking in order to fix them.
I guess in short, I agree with you. Over these other ideas that have gotten significant attention, none really seem to be of high enough quality to be put into bitcoin in their current state.