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.