It could, but with the current WebRTC implementation initial connection establishment between peers requires a signaling server to coordinate network information.
- 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.
For P2P over the broader internet: Either use another channel to convey the token or use a native application that can speak UDP/TCP to do actual distributed P2P transfers.
The situation isn't pretty, but there's more than what WebRTC with its single-use sessions offers.
see https://webrtc.org/getting-started/peer-connections.
There is a youtube video on writing a webrtc chat app and (during development) the developer simply copies and pastes between two windows on the same computer. Webrtc file transfer, text chat and video chat all use this information. In addition if one is negotiating connections across NAT servers you use STUN or TURN servers (there are open ones) to establish NAT. Your local computer/phone/whatever will send need to tell the other side what your NAT address is and STUN will do that.