Very interesting article, thanks!

I hadn't considered (1) (cut-through) at all, at least I don't remember discussing it, but I totally agree that it's a very substantial possible angle of usage, and has economic incentive, at least if payjoin is a regular thing. A lot of it interacts with output substitution though, something we didn't discuss much until the end of the BIP78 discussion (and it was mostly motivated by address types iirc). I was and remain leery of it; as you already saw recently, it requires a very "hardened" security model, if anything is slightly off it introduces theft vectors. Still, if people get things right, for sure this kind of flexibility achieves something. It's just more dangerous.

As for (2) it feels very 'meh' to me. Even the concept that a receiver-merchant saves something is dubious because it's just kind of "cheating" the sender. And gains very little percentage wise anyway. Meanwhile you can save overhead, too, if you just accept 100 normal payments and then do a batch send of them later. (i.e. normal non-payjoin batching).