Exactly. If WebSockets were an option, then WebRTC will be pretty trivial and absolutely doesn't require any STUN/TURN.
(The main issue, and this has nothing to do with the client API, is that WebRTC implementations tend to end up assuming unique ports for each user--which would be needed to help with NAT--but if you aren't behind NAT then the ICE layer already has a connection ID so you should be able to multiplex them all over a single open port.)
One big issue was also being able to demux DTLS traffic. You could do it off the 3-tuple of the remote host, but that would fall down sometimes.
I am really excited for DTLS connection ids[0] to land. Then you will have everything you need to run ICE+DTLS (and SCTP over that) and be able to demux/load balance it easier.
(The main issue, and this has nothing to do with the client API, is that WebRTC implementations tend to end up assuming unique ports for each user--which would be needed to help with NAT--but if you aren't behind NAT then the ICE layer already has a connection ID so you should be able to multiplex them all over a single open port.)