Both it and CoinSwap appear to enable two party mixing, with unlinkable transactions, providing an anonymity set of all similar transactions happening concurrently. Both depend on what you call hash locking. Both are complex but the complexity is in different spots: in CoinSwap, it requires a number of rounds and a third party Carol. In the paper, it requires a complex setup, including the cut-and-choose.
A couple points of comparison come to mind:The paper proposal has a probability of cheating related to a security parameter, and requires communications in the setup phase linear in that security parameter (though I'd previously described a cut-and-choose communications optimization that could help).
The paper's proposal has an anonymity set of only all such transactions, as the hash commitments will be made public. In the case where a CoinSwap is successful the transactions just look like 2-of-2 escrows which likely results in a larger anonymity set.
CoinSwap doesn't require a third party, Bob can be alice and I noted this in the post.
I just thought it was easier to describe using three (or four) parties then trying to make distinct one party operating in multiple roles... an effort to try to simplify some of that complexity you mention.Generally I prefer protocols that have complexity moved into the initial setup, but the widened anonymity set achieved here by using all escrow transactions is probably worth losing the ability to front-load the complexity.