My understanding is that currently people set up a STUN/TURN server to relay WebRTC, so it's not really used as P2P but there is still some benefit to the protocol itself.
To move to true P2P for WebRTC seems impossible, as even if 80% of web users were on IPv6 without NAT (and even 80% seems a bit hopeless at this point considering we've been transitioning to IPv6 for 20 years now), you'd still need a fallback configuration for the 20% that don't. There doesn't seem to be a feasible gradual transition strategy.
This is not really my area of expertise, so I'd love to be proven wrong.
STUN doesn't relay. It assists with P2P connection setup. TURN relays, and is intended as the path of last resort. The vast majority of WebRTC traffic is P2P.
The vast webrtc traffic is in reality between a peer and a sfu (selective forwarding unit) on a server. There is almost none real p2p webrtc traffic happening in reality because most people don‘t have enough upload bandwidth to transmit their video to all participating peers.
> There is almost none real p2p webrtc traffic happening in reality because most people don‘t have enough upload bandwidth to transmit their video to all participating peers.
Many providers choose to use SFU's even when not needed because they have features like recording that require it. I've gotten much better quality and latency on normal webrtc than I have over slack, teams, hangouts, even over bad mobile networks.
To move to true P2P for WebRTC seems impossible, as even if 80% of web users were on IPv6 without NAT (and even 80% seems a bit hopeless at this point considering we've been transitioning to IPv6 for 20 years now), you'd still need a fallback configuration for the 20% that don't. There doesn't seem to be a feasible gradual transition strategy.
This is not really my area of expertise, so I'd love to be proven wrong.