1. The resulting txids are not stable.
CTV commits to enough tx information such that given the txid:vout of the covenant-encumbered output, you can predict the txid of the spending tx permitted by CTV (and of the entire transaction graph descending from it).
This property could be important for some of the proposed CTV use-cases, like channel factories.
2. APO will only be available on Taproot, which some people might prefer
to avoid for long-term multi-decade vault storage due to QC concerns. (also see my previous post on this thread [0])
3. Higher witness satisfaction cost of roughly 3x vbytes vs CTV-in-Taproot (plus 33 extra vbytes vs CTV-in-segwitv0 in the case of a single CTV branch, for the taproot control block. with more branches CTV-in-taproot eventually becomes preferable).
4. Higher network-wide full-node validation costs (checking a signature is quite more expensive than hashing, and the hashing is done in both cases).
5. As APO is currently spec'd, it would suffer from the half-spend problem: if you
have multiple outputs encumbered under an APO covenant that requires the
same tx sigmsg hash, it becomes possible to spend all of them together
as multiple inputs in a single transaction and burn the extra to mining
fees.
If I'm not
mistaken, I believe this makes the simple-apo-vault implementation [1]
vulnerable to spending multiple vaulted outputs of the same denomination
together and burning all but the first one. I asked the author for a
more definitive answer on twitter [2].
Fixing this requires amending BIP 118 with some new sigmsg flags (making the ANYONECANPAY behaviour optional, as mentioned in the OP).
This is definitely possible but also means that APO as-is isn't a CTV-replacement candidate, without first going through some more design and review iterations.
shesek