FWIW, I think the rmain reasons to do CAT+CSFS is to validate oracle messages and pubkey delegation.  The ability to covenants would be secondary and would mostly serve to get us some real user data about what sort of covenants users find especially valuable.

I don't think this should be discounted.   I think it's worthwhile to willingly include possibly less-than-awesome, but proven perfectly-safe opcodes, knowing we will have to validate them forever, even if new, cooler and more widely-used ones replace them years from now.

I honestly don't think the development of the latter will happen without some version of the former. 

Personally I am satisfied:

  - the safety of covenants, in general, is covered by how addresses are generated
  - fears of forced forward-encumbrance are not any worse than can be easily done today 
  - ctv+apo, cat+csfs are fine, but we should pick ones that everyone thinks are "good enough for everyone who cares about them"
  - they are not an undue burden on nodes in terms of validate-cpu-cycles-per-byte (have we proven this?)
  - the complexity is low, code is easy to validate
  - won't introduce DDOS attack vectors (also needs to be proven i think?)
  - the game theory underpinning selfish miner support of the chain won't be altered by causing a widespread use of on-chain leveraging instruments (shorting bitcoin on-chain would be dangerous, for example)