That makes sense. But it heavily depends on whether client or software you use have ability to mitigate those attack.
Yep, I'm excluding any wallet level implementation details and focusing on the protocols. As you indicated further, the most trivial way to forfeit privacy in this process is reuse the same IP address for each "identity" you assume:
Don't you need tor or something to prevent everyone from learning everyone's IP?
Any transaction privacy system that hopes to hide user's addresses should start with some kind of anonymity network. This is no different. Fortunately networks like Tor, I2P, Bitmessage, and Freenet all already exist and could all be used for this. (Freenet would result in rather slow transactions, however)
However, gumming up "taint analysis" and reducing transaction sizes doesn't even require that the users be private from each other. So even without things like tor this would be no worse than regular transactions.
At very least, BTCPay doesn't use Tor by default and in certain cases i expect to detect whether it's deanonymization attempt or network problem.
Tor is used by default for the WabiSabi coinjoin plugin on BTCPay Server.
Is that from section 7.1.2? What exactly do you mean by marginal cost?
Yes, that's the section. There's 0 marginal cost for an attacker to DoS a WabiSabi coinjoin round just like there's 0 marginal cost to get another plate of food at an all-you-can-eat buffet. Since you will pay to transfer any UTXO you own at some point anyways, there's no disincentive for attacking with it before giving up ownership in the future.
In the JoinMarket framework, this 0 cost attack applies to malicious takers who propose offers to makers without ever intending to complete them. Makers will indicate common ownership of their unspent coins to the taker, who never ends up paying the mining fees to mix that maker's coins.