It depends on applications and users (home, mobile, corporate). Some anecdotal evidence suggests that 2/3rds of user pairs can't connect without a relay server with all the tricks deployed (NAT traversal, IPv6 when available, client side port guessing for certain predictable NAT implementations), in other case it is 9 out of 10, or almost everyone. However, if you and your friend can't connect, what are the benefits of knowing that 100 other users succeeded?
That's why WebRTC supposes that the service provides some TURN relays from the start, and any commercial application comes with its own relays or uses third party infrastructure. That's why when you see any mention of “peer-to-peer” in this context, it actually means “which percent of monthly traffic on average we can offload”.
Notice that those are stats for unique data transmissions between one user and another. When data is not unique (same live video segments to many users), we can have one-to-many sharing, and the percentage of offloaded data can grow much more. Candidate selection for reliable seeding role is non-trivial, though, and it might only make sense when the swarms are big enough to contain enough peers that accept incoming connections.
As other said, quite a lot of those services exist. When they don't provide TURN servers, they have questionable utility (but can be used in the same local network). When the author does host a server for others, you obviously don't want to shove gigabytes of data into it (and the safe bandwidth limit is usually too slow for that anyway). Network connections do not seem to be the main problem, writing the client code properly, and in a way compatible with multiple browsers and unexpected events does.
If you have a non-recurrent need to transfer some data, and no server at hand, Syncthing volunteer-run relays seem to have some capacity available.