I agree with the general thrust of this, but libwebrtc has a tendency to have Google convenient defaults which are distinctly non obvious, such as the quality vs framerate tradeoffs being tied to what Hangouts needs to implement as opposed to useful general purpose hooks. (I hope they have updated that API since I last looked). Once you know how to poke it to make it do what you want, which tends to require reading the C++ source, it's definitely got a massive head start, especially around areas like low level hardware integration. Even bolting on ML inference and so on is not hard. The huge point though is everyone knows everyone has to talk to libwebrtc at some point, so it is the de facto implementation of SDP etc.
Curiously I was working on a webrtc project for about 18 months which also hit the wall, however, since then I have learned of several high profile data only libwebrtc deployments, which really just use it in the way classic libjingle was intended to be used, P2P, NAT punching etc. I'd go so far as to say if you don't have a P2P aspect to what you're doing with libwebrtc you're missing the point.
The big picture though is there seems to be a general denial of the fact that web style CDNs and multidirectional media streaming graphs are two totally different beasts.