It's not just WebRTC. Basically, if you want things to work when both endpoints are behind typical NATs (a very common situation), you need some kind of signaling system. There are several reasons for this:

- NAT bindings are usually not stable over long periods of time - Many NATs implement what's basically a stateful inspection firewall, which means that you actually need to send a packet out to the peer's address before it will be allowed to send a packet to you from the outside - In some nontrivial fraction of cases, you actually need to relay traffic through a third party.

The result is that you need some coordination protocol to set up the connection and that has to go through some service which is accessible from the endpoints; generally this means some type of service. So, yes WebRTC is designed this way, but it's basically a constraint of any system of this type.

For more on this than you wanted to know, see: https://educatedguesswork.org/posts/nat-part-1/ and following posts.