Sure, and that's better, I agree, but XMPP also works the same way, but it's base protocol is much lower layer (a TCP connection instead of a higher layer protocol like HTTP). The point is that the default (which is always what most people will stick with), is too cumbersome and inefficient for realtime applications.
Agreed that XMPP is much lighter in terms of server processing than Matrix (they are doing entirely different things, after all). In terms of transport, yes: Matrix's default HTTP/1+JSON transport is heavier than baseline XMPP.
I haven't checked but my hunch would be that HTTP/2+JSON would be very similar to typical XMPP in terms of bandwidth, if not better, and obviously requires no spec changes; just an HTTP/2 capable client & server/LB.
In terms of what transport people use: well, I assume end-users will use whatever the best performing clients implement. Riot is the flagship client and will obviously do better than HTTP+JSON; meanwhile we've had a lot of pressure from Weechat to start using a better transport (e.g. websockets) for them (https://riot.im/app/#/room/#matrix:matrix.org/$1477998960439... meanwhile Ralith (the author of the NaChat Qt matrix client) has been working himself on a capnproto transport due to wanting something faster & better than the baseline.
So we're not particularly worried that most people will stick with the baseline for daily usage. Instead, it'll act as a really nice and easy on-ramp for new developers, debugging/deving on the API, etc. Anyone serious will end up using a better transport.
Finally: it's worth noting that adding E2E by default into Matrix increases the complexity of clients enormously - so we expect the plain `curl -XPUT /_matrix/client/r0/rooms/.../m.room.message --data { "body": "hello world" }` style APIs to increasingly be just for experimentation, initial dev and prototyping. As soon as you want to start talking E2E folks will reach for a full client SDK, at which point they will get access to both E2E and whatever weird & wonderful transports that SDK happens to provide. So, again, the majority of users won't be on plain ol' HTTP.
