[Written on Facebook in response to a post by Glenn Fielder.]
I implemented a proof of concept WebRTC server over the Christmas holidays specialized for use by dedicated server games with UDP-based protocols. The ICE/SDP side of things is like 100 lines if you only code the parts you need rather than using libstun or whatever (the server's SDP offer specifies its public IP, so you just have to implement the STUN responses when the client starts to bang on your ports), and you can likewise hard code the tiny subset of SCTP you need for data channels. The only thing you really need external code for is the cryptography for the ICE authentication and for DTLS, where I used mbedtls.
One thing you didn't mention in your article is that WebRTC data channels (i.e. SCTP over UDP) are congestion controlled per WebRTC connection with a TCP-like algorithm even if you set the no-ordering, no-retransmit options, so you can't use them to efficiently tunnel a UDP protocol that wants to do its own congestion control, like most games. However, I got around that by being very naughty and sending fake ACKs from the server (I always sent an ACK up to the most recently received client message), which maximally opens the client's congestion window even if there are packet drops (which SCTP normally interprets as signs of congestion), effectively disabling congestion control, which let me tunnel a game-like UDP protocol without hitting any congestion control clamping in either direction. As naughty as it is to break congestion control at the transport layer like this (I was joking that the IETF would dispatch an assassination squad), it's not any worse than a raw UDP flow since it just defers any rate limiting or congestion control to the application layer.
Anyway, I got all this working as a drop-in UDP tunneling solution, but never got around to tidying it up enough to release. Given how slow the wheels of standardization turn, I think a more production-ready version of this approach would have a lot of value since it works today with any browser that supports WebRTC data channels.