It's not that anyone benefits from having the message delivered more than once at the application level; actually, it's the opposite. The note that messages may

It's not that anyone benefits from having the message delivered more than once at the application level; actually, it's the opposite. The note that messages may be delivered more than once is a warning to developers who might expect exactly-once semantics. However, it is a benefit in that allowing for more-than-once-delivery affords better performance. Think of it from an algorithmic perspective: if you want to send a message exactly once, you have to wait around for acknowledgement that your message was accepted. If you instead don't mind sending duplicates, you can fire off the first copy, wait for an ack for a while, and then fire off again to another node (in case, perhaps, there was a network partition). If it turns out that both copies arrive at their final destination intact, your application now has to deal with duplicates. But, that's faster than the alternative. So it puts more burden on the developer to deduplicate where necessary (or program in a model where duplicates don't matter anyway, such as with CRDTS), in exchange for greater throughput.