Antoine,
One high level reason to not prefer APO is that it gets 'dangerously close' to fully recursive covenants.
E.g., just by tweaking APO to use a Schnorr signature without PK commitment, Pubkey Recovery would be possible, and fully recursive covenants could be done.
Short of that type of modification, you can still do a "trusted setup" key deletion covenant with APO and have a fully recursive covenant set up. E.g.
<1 || N-N MuSig> APO
where the N-N MuSig pregenerates a signature of a transaction that commits to an output with itself, e.g., using SIGHASH_SINGLE.
By itself, this is not super useful, but does create the type of thing that people might worry about with a recursive covenant since after initialization it is autonomous.
One use case for this might be, for example, a spacechain backbone that infinitely iterates, so it isn't entirely useless.
If other opcodes are added, such as OP_IN_OUT_AMOUNT, then you can get all sorts of recursive covenant interesting stuff on top of that, since you could pre-sign e.g. for a quanitzed vault a number of different deposit/withdraw programs as well as increasing balances depending on timeout waited.
Therefore, I think reasonable people might discriminate the "complexity class" of the design space available with just CTV v.s. APO.
In contrast, the approach of smaller independent steps:
1) Adding CTV
2) Adding CSFS (enables APO-like behavior, sufficient for Eltoo)
3) Adding flags to CTV, similar to TXHASH, or just adding TXHASH (enables full covenants)
4) Ergonomic OPCodes for covenants like TLUV, EcTweak, MAST building, etc (enables efficient covenants)
is a much more granular path where we are able to cleanly 'level up' into each covenant complexity class only if we deem it to be safe.
<redacted>comment about timelines to produce a modified APO</redacted>
Best,
Jeremy