A malicious coordinator may tag users by providing them with different issuer parameters. When registering inputs a proof of ownership must be provided. If signatures are used, by covering the issuer parameters and a unique round identifier these proofs allow other participants to verify that everyone was given the same parameters.
As noted, you can register multiple inputs with WabiSabi to verify that the parameters match each other.
A malicious coordinator could also delay the processing of requests in order to learn more through timing and ordering leaks. In the worst case, the coordinator can attempt to linearize all requests by delaying individual to recover the full set of labelled edges. This is possible when k = 1 and users have minimal dependencies between their requests and tolerate arbitrary timeouts but issue requests in a timely manner.
As noted, clients would be able to detect this and defeat it by disallowing arbitrary timeouts.
Similarly the coordinator may delay information such as the set of ownership proofs or the final unsigned transaction. In the case of the latter, this can be used to learn about links between inputs. This is because a signature can only be made after the details of the transaction are known. If the unsigned was only known to one user but multiple inputs have provided signatures, it follows that those inputs are owned by the same user.
If I understand it correctly, this is handled by using a different Tor identity for listening to round updates than the Tor identities you register inputs with. Because the coordinator does not know which Tor identity is listening for which inputs, they do not know who to target with this delay.
Since the coordinator must be trusted with regards to denial of service a more practical variant of this attack would involve more subtle delays followed by sabotaging multiple successive rounds during the signing phase in order to learn of correlations between registrations while maintaining deniability.
Clients abandon rounds after multiple successive failures as a basic way to prevent this.
That makes sense. But it heavily depends on whether client or software you use have ability to mitigate those attack. 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.
I know you didn't mention it, but I disagree with this conclusion in section 7 of the WabiSabi paper:
Denial of service is not costless because unspent transaction outputs are a limited resource.
This is incomplete because the marginal cost of a DoS attack is zero if you are going to spend your UTXO anyways.