(Author of the spec here)
The protocol could just as easily go over a WebSocket as HTTP (you'd have to change authentication mechanism, but that would be trivial). The only reason we don't do that at the moment is:
1. Browser support (we support back to IE8, unfortunately)
2. Lack of GZIP compression (particularly of responses from the server); this was being worked on last time I looked, but I haven't checked recently to see if it's been implemented yet. This is crucial for saving bandwidth.
That would get rid of your HTTP overhead; I will put some mention of that in the spec (I think HTTP support should be required, and WebSocket support optional).
As for JSON vs. binary:
* There are libraries to use JSON everywhere – binary protocols would require everyone to implement another parser, adding extra difficulty for adoption and a surefire source of bugs.
* JSON is readable over the wire, binary is not. Trust me, in the real world, this is a huge advantage for debugging all sorts of things.
* JSON can be used trivially in a web app. Apparently this World Wide Web thing might catch on.
* The parsing overhead of JSON is not too large; yes it's longer than a binary protocol, but it hasn't been a bottleneck for us, even on mobile.
