The main answer is that we don't really have a fully spec'd Eltoo design for Anyprevout (or CTV+CSFS), and that's something that requires more thorough investigation to make the correct primitives for Eltoo, including things like SIGHASH_BUNDLE.
The main issue that arises with (any) eltoo proposal is that you have to pay fees, somehow, and there is a Dust limit.
With APO Eltoo there is an issue that because the different sighash modes let you only sign one or all of the outputs, it's difficult to add fees to the transactions in it if they have >1 output. Thus (how I've seen eltoo described, I could be off) is such that one root transaction with 1 output drives state forward where outputs can be dynamically added, and the second layer of transaction expands to HTLCs but is not time sensitive to resolve, but I'm not sure how it's proposed fees are added to that. One option is to allow adding inputs (but not outputs) and you have to craft perfectly sized fee paying outputs, another option is CPFP on each HTLC. This is an option at this phase since every party should have some output (remember, eltoo is N party). This doesn't work at the state update level of eltoo since we don't want to have to create N outputs for CPFP-ing.
In CTV world you can have the option of adding an input, but you can't dynamically add change. So if you have N parties, you might sign N transactions to allow up to N parties to add an (perfectly sized) input to add fees. These input slots can accomodate any UTXO (without a relative timelock set). The state updates can also have a CPFP anchor output, that could be anyone can spend, it could also have a CTV congestion control tree of anchor outputs to allow any party to pay fee with only log4(N) cost to get a single CPFP hook, and constant overhead to get N hooks out.
One of the benefits of a CPFP approach over a RBF with new inputs approach is that it is slightly simpler to deal with various types of pinning attack when your transactions can't be dynamically changed by a third party.
Alternatively, my Transaction Sponsors proposal would benefit both APO and CTV based fee paying by moving the payment of fees to out of band.
Overall, short of a fee paying solution, the protocols are pretty much the same.
Lastly, as the question asker has insinuated on other platforms, he wishes to oppose CTV unless we prove that CTV+CSFS works for Eltoo, I'd advise against that. The point is that the main state update mechanisms described by Eltoo as implementable via APO can be achieved with CTV + another possible proposal (CSFS) that is a little simpler than APO, but does not currently have a BIP. In either case, the main thing that should happen is more research into Eltoo to fully prove out the requirements for the system and then we can adopt the set of upgrades required to give us the best version of that. I suspect that means something like transaction sponsors or sighash bundles, but it's not my prime area of research. CTV has enough 'other stuff' going on that witholding it's release pending ongoing research on the lightning network seems like an unforced error.
