If you compare it to speed of adoption of WebSockets, variety of WebSockets implementations and how much it is used commercially.
There are many conversations by many developers who as well attempted using WebRTC for server-client communications, and it is apparent trend.
One of the developers of WebRTC team at Google who worked on DataChannel and network code admits himself that their team is aware of complexity and difficulties with WebRTC in server-client cases: https://news.ycombinator.com/item?id=13266874
WebRTC is specifically designed for server-client cases. In the case of video and audio, the server is called a "mixer" or MCU. This is extremely important for large multi-user conferences - if it weren't for a mixer, you'd have to upload your video once for every user, burning all of your upload bandwidth. Examples of services using this are Appear.in Premium and Cisco Spark.
Note that games are the #1 use case mentioned in the Datachannel draft [1]. It's perfectly fine to argue that the standard is bad, but it was designed for these use cases.
The Google developer you linked seems to be arguing for improving the WebRTC C++ library, not changing the protocol.
[1] https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-1...
This is exactly what I pointed out: WebSocket has much larger implementation base across browsers and back-end due it's simplicity.
> There is also a list of various transparent fallbacks that can be implemented like long polling which WebRTC doesn't have.
Those fallbacks were temporary solutions during adoption of WebSockets which today are obsolete as WebSockets are well adopted and pure WebSockets implementation is fairly simple.
This is what we want from WebUDP for server-client cases, which we can fallback to WebSockets if WebUDP is not supported.
There is also a list of various transparent fallbacks that can be implemented like long polling which WebRTC doesn't have.
