He states that using MuSig and other distributed signing solutions are not acceptable for this case as they all require interaction for guarantee of payout. With OP_COSHV Taproot key, a user can request a withdrawal from an exchange which some time later pays out to a lot of people without having to withdraw multiple times and then pay. The exchange doesn't have to know this is what the user did. They also don't have to tell the user the exact inputs they'll spend to them or if they're batched or not. Furthermore, it allows the exchange to take inbound payments to their hot wallet and move them into cold storage with pre-set spending paths. None of this works well with just pre-signing because you need to ask for permission first in order to do these operations, but with OP_COSHV you can do so without needing permission. Jeremy's explanation leads to an objection from ZmnSCPxj who argues that there are certain cases where OP_COSHV is not useful. In CoinJoin, the initial funding transaction must be signed by participants anyways after checking that the output is correct. Any spend that is not a signature spend is going to defeat the purpose of CoinJoin trying to be private by imitating "typical" spends. If OP_CHECKOUTPUTSHASHVERIFY path is used, the privacy of CoinJoin is lost by reducing anonymity set. Similarly, in Channel Factories, the initial funding transaction must be signed by the participants anyway after each initial sub-channel initial commitment / initial update+state transaction is signed. In both above cases, the issue of users dropping out during the step of signing the initial funding transaction is unavoidable even with OP_CHECKOUTPUTSHASHVERIFY.