My rationale for support of various covenant proposals:

To start, I am generally in favor of basically any covenants at this point. Bitcoin in its current form can only make 2 party protocols without huge amounts of interactivity and this greatly hinders scaling and threatens if people will actually be able to self custody their coins in the future. I also think we should be activating things in a timely manner, the window for soft forks is slowly closing and I would hate for bitcoin to ossify where custodians are our only solution to scalability. Politics aside, lets get into it.

OP_CAT: This one is a beast. OP_CAT will essentially enable everything, just in a very inefficient way. It being inefficient is not necessarily a bad thing, it allows for other proposals to be activated based on market demand instead of guessing what people want like we have for the last 15 years. Cat also isn't just a covenant proposal, concatenating things is a useful thing and will allow for lots more things (merkle trees, SNARKs, etc). It's extremely simple in implementation so there's basically 0 risk for bugs, the real risk is what it enables. The only thing that can kill bitcoin imo is fucking with mining incentives and I don't think cat makes it any worse than it already is. OP_CAT is my favorite overall (even before I started my current job) but if we're activating cat, i think it'd be stupid to not activate it along with some other op codes.

OP_CTV is the next most obvious upgrade to bitcoin, it is extremely limited in nature and essentially just locks the txid of the next transaction or acts as a pre-signed transaction, one of the most common things done in bitcoin today. CTV's main criticism today is that it doesn't do enough but I think it stands just fine on its own so long as its coupled with some other op codes.

OP_CSFS (check sig from stack) isn't really a covenant proposal but when paired with CTV, allows for LN symmetry (or eltoo) and makes a ton of sense. It's a simple op code (checks a sig), and doesn't add any new assumptions or add any new concerns about DoS.

OP_INTERNALKEY, also not a covenant proposal, all this does is push a pubkey onto the stack, saving 31 bytes. This is such a simple op code, I'm honestly surprised this wasn't included in base tapscript.

These are the ones that I'd most favor, I think this enables a million new ways to do layer 2 applications on top of bitcoin, some that we know will work (eltoo) and some that will be experiments (CatVM) and others that haven't even been invented yet. This also leaves the door open for more fine grained proposals in the future if we sufficient demand for other applications (ie vaults).

I'll get into the remaining proposals on why I am okay with them but would rather have the previously mentioned op codes.

OP_PAIRCOMMIT, not a covenant proposal but included in the LNHANCE set of op codes. This essentially is just OP_CAT with extra steps, it concats 2 items and then hashes them and puts the hash on the stack. I would bet on a long enough timeline people figure out how to do op_cat things with pair commit, so lets just do op_cat instead.

OP_VAULT is great but not something that greatly excites me atm. I think vaults are a good idea but from what I've heard, there isn't much demand for vaults as of now (at least today's presigned tx version). This also doesn't address my main concern of scaling self custody. However, I do think its a great idea and can probably can still be used in ways to enable new layer 2s, so I am all for it.

OP_TXHASH is basically just OP_CTV++, so I am in favor of it. However, my understanding is there isn't a battle tested implementation yet and just feels like overly complicated CTV. Imo, TXHASH is a great follow up op code because we can fine tune it to what people are actually using covenants for, instead of prematurely optimizing everything with no data.

OP_CCV, I know the least about this one but i think MATT is a good idea and in general favor of it. If this was the only way we'd get covenants into bitcoin, then I'd be fine with that for now.

APO feels dead these days, LNHANCE has usurped it in every regard. LNHANCE enables everything APO does but in a more fine grained and intentional way. APO is accidentally a covenant proposal while also not being very general, making it not very useful for applications outside of ln symmetry.