It's useful when you have computers that talk to each other over the internet, likely without public interfaces, and using protocols that may or may not be secure.

this would mean, for instance, torrents that are wireguarded between peers by default. sure you will see tons of IPs connected via wireguard but who is going to bother intercepting them?

*shudders*

The loss of a "central server" or whatever never matters.

Im using it for Payload[1] in for LAN and WAN transfers (if possible). Reduce operational costs (especially if you run on public clouds and have to pay extortion rates for egress) and also you must use it to capitalize on latency/throughput in LAN. Moving data from A->server->B means your need multiple servers on the edge, which means you kinda need to depend on mega-corps. If your destination is closer it’s easier for your application infra. I’d like to reverse the question, why send all data through another machine in the cloud if you don’t need to?

That said, p2p being flaky and bad is real. It’s a self-fulfilling prophecy, because middlebox engineers say ”let’s add these layers of garbage and nobody will notice unless they use p2p but its so bad who uses it anyway”. Well, yeah. It’s worse because of you! Philosophically, I also think p2p is a necessary precondition to a decentralized internet without tiers (ie client and server separation).

Anyway, rant aside, you have to currently have a relay backup if you need availability. P2P will fail often even with the smartest hole punching algorithms. This makes things more complicated, because you need a hybrid solution. However, it’s not as complicated as WebRTC, that thing is an overengineered mess. It works, but I don’t like the complexity it brings.

[1]: https://payload.app/

There are a lot of things that do P2P under the hood, usually with cloud relay fallback so it always works. You just don’t hear much about it because it’s not a selling point, just an under the hood detail.