Ideally, it creates a lot of outputs, so that the ownership is smeared more, but this has a cost at the time of the coinjoin. The protocol becomes more stable with respect to input choice, similar to how NOINPUT may work, OP_COSHV outputs are spendable without knowing what the TXID will be. This culminates in being able to open channels from a coinjoin safely, which is believed to be difficult/impossible to do currently.Using Coinjoin for congestion control increases blockchain usage by one TXO and one input, ending up with more bytes onchain, and a UTXO that will be removed later in (we hope) short time. It improves QoS for most users. For receiving money pending spendable but confirmed payment is superior to having unconfirmed funds. For sending money, being able to clear all liabilities in a single txn decreases business exposure to fee variance and confirmation time variance. It also helps to have a backlog of low priority txns to support the fee market. Overall block bandwidth utilization is fairly spikey, so having long term well-known outputs that are not time sensitive can be used to better utilize bandwidth. While the finite loop support by this opcode appears (at first glance) to be usable as the "stepper" for an offchain update mechanism, there is no way to implement Decker-Russell-Osuntokun (or any offchain update mechanism) on top of this opcode, so it cannot be supported for replacing SIGHASH_NOINPUT with this opcode. Lastly, it is mentioned that there's no 'replacing'. Neither NOINPUT nor COSHV are accepted by the community at large yet, and they do different things.Channel factories created by this opcode do not, by themselves, support updates to the channel structure. But such simple "close only" channel factories can be done using n-of-n and a pre-signed offchain transaction (especially since the entities interested in the factory are known and enumerable, and thus can be induced to sign to enter the factory). This basic mechanism should work for Bitcoin Lightning. For example, in the script at a leaf node, if the uncooperative script branches in the leaf are blaming Alice or Bob, the cooperative closing skips the extra transactions.