[Nullabillity]

It would probably be possible for smaller communities today, given how cheap bandwidth already is. For comparison, I'm currently paying ~$13/mo for a (symmetric) gigabit connection.

The main reasons for transcoding are downstream bandwidth usage and codec support. WebRTC mandates VP8, so codecs shouldn't be an issue. Downstream bandwidth usage probably wouldn't be a major concern when it's viable to stream at 1080p to thousands of viewers from a home connection (though I doubt that's going to happen soon). So you could probably ignore transcoding entirely.

However, marketing would probably be an issue, since this architecture would prevent streamers from having more than about a hundred watchers, meaning that the big fish would stick to Twitch. That said, I suppose you could have a failover system, where larger streamers would switch to a relay-based system.

[Gaelan]

Where do you live? Internet is way more expensive in the US.

[Nullabillity]

Stockholm.

[MBCook]

If you're lucky enough to have Google Fiber in the US it's $70/mo for symmetric gig, IIRC.

[TD-Linux]

You can also fall over to a classic client/server model with WebRTC for one to many broadcasting, while still keeping the advantages of very low latency (and reusing much of the same code).