WebRTC is not a bad technology for this project. The answer to this question is: little bits of different reasons.
1. We don't have a ton of resources (as in people working on it), so we have to be laser focused on making the implementation as simple as possible, to prove out the initial "v0" set of use cases. Straightforward client/server HTTP is the simplest possible thing. A couple dozen lines of node.js or python code are all that is necessary to throw up a FlyWeb server on a smart device. WebRTC support is way more complex, and less accessible to developers due to that complexity.
2. WebRTC is peer to peer, but it's also implicitly "cloud". One of our goals is to focus on approaches that are purely local. This is my personal opinion, but the minute that smart devices are somehow addressable from 'the internet', they become way more creepy - the surface area they expose to billions of people makes them troubling. Limited local-network (and eventually network-less local-area) HTTP is implicitly not "visible" to the entire world, which is a nice property.
3. Fundamentally, the "core strength" we're trying to leverage here is that the web platform lets you easily and securely "stream" applications between computers. That's what you do when you go to gmail or facebook or whatever - servers on the internet incrementally stream an application to you that's encoded in terms of HTML/JS/CSS/etc. WebRTC is a message-passing technology, which is not quite the core fit we're going for. Web and HTTP are the core of the app-streaming concept, so we're building on that.
