Our own data vindicates what we've read elsewhere: about 90% of users can successfully make peer-to-peer connections. So actually most users can make connections, and a minority cannot.
The main reason the minority cannot is because of stupid network-address-translation (NAT) middleboxes on the Internet. Basically IPv4 addresses more or less ran out years ago, and the workaround is to hide multiple separate devices on different ports behind a single IP address. The NAT box figures out which ip:port combinations go to which devices. However there are lots of ways of doing this, and not all of them allow direct peer-to-peer connections.
In principle, peers ask a STUN server for what their ip:port looks like from the outside Internet, because they don't know themselves when behind the NAT. Basically it's a simple "tell me my IP address" request. The STUN server sends it back, the signalling server exchanges the ip:port for each peer, then they try to connect to each other. However here's an example of one kind of particularly annoying NAT: a large office where say 1000 computers are actually hidden behind not just one IP address, but 5 different IPs, which are chosen semi-randomly for each connection. So a peer from that office asks the STUN server for its IP address, it returns one of the 5 IP addresses, that is sent to another peer, then it tries to connect to them but the NAT chooses a different IP out of the 5, and the connection fails. There are a few other kinds of NAT that break peer-to-peer connections in similar ways.
You can work around this for the 10%: run a TURN server. This is just a relay - both peers connect to the TURN server, and the server forwards data between them. That brings the total connection success up to something like 99%, but then you have to pay the bandwidth bills for everything running through the server. We already pay hosting fees to run the signalling server and we do that for free, but racking up bandwidth bills for actual gameplay data is a bit beyond what it's sensible to offer for free. So if you're worried about the 10%, you can run your own TURN server.
Another good workaround is run the host on a dedicated server which is not behind NAT. That should also work for a wider audience since some problems come only when both peers are behind NAT, but it still costs money.
That's all more to do with the architecture of the Internet than WebRTC, HTML5 or Construct 2. Native apps are affected identically AFAIK, because it's the same network they're connecting through. This is why we need IPv6!