I believe websockets only support outbound traffic so given that limitation I'm not sure how useful it would be for games. WebRtc while a heavier stack would probably be more useful IF you can coax it to get close to the performance of UDP.
WebSockets are already available through the unitypackage here: http://docs.unity3d.com/Manual/webgl-networking.html They don't only support outbound traffic, they are bidirectional, but a browser app can only function as a client so you must send traffic via a server. They are slightly more expensive than a plain TCP connection, with the same delivery characteristics, i.e. everything is reliable in-order. I made a plugin for WebRTC, wrapping PeerJS. I might make another for plain WebRTC if I get time. See this thread: http://forum.unity3d.com/threads/unitypeerjs-simple-webrtc-support-for-unity-webgl.310166/ I am not convinced about WebRTC though, it currently has really crazy packet header overheads and I don't think the people developing it have any interest in games, nor appreciation of games' requirements.
Yeah sorry I guess a better way to put it is as you said requires a server (not outbound only). My main point is you couldn't get inbound traffic without the server in a peer to peer sense (browser a to browser b). I don't mind having the server for the discovery phase but after that I would like to drop the middleman. Yeah those packet overhead costs are high. How was the latency that you saw?
I didn't measure the latency - I didn't even test with more than one machine, just two tabs in Firefox (well, I tested Firefox-to-Chrome as well). It should be the same as normal UDP though, as it is tunnelled over that, just with lots of headers, and mandatory encryption.