Overall, it makes the impression on me like it was designed by someone who doesn't know much more than how to build web apps and therefore is afraid of anything not HTTP, and so will use HTTP no matter what, even if there are essentially only disadvantages compared to pretty much any alternative you could come up with.
(Oh, and also, they claim being "RESTful", without being anything like that ...)
The "simplicity" of HTTP I mentioned in the Matrix blurb refers to the fact that RFC2616 is relatively compact and self-contained, whereas SIP/SIMPLE/MSRP involves a huge number of RFCs, different protocols (SIP,SDP,MSRP...) and really is a lot more complicated to implement than just doing GETs and PUTs.
Now, the irony is that rather than being "designed by someone who doesn't know much more than how to build web apps" - it's more the other way round. Our experience is mainly with SIP/RTP/STUN/ICE/TURN etc; genuinely RESTful APIs are relatively new territory for us.
I would genuinely love to know what aspects of the Matrix client-server (or server-server) API is 'not anything like RESTful' - it's not too late for us to change the APIs (they've already been rewritten several times, oscillating between more or less RESTful purity), and half the point of releasing Matrix in its current early proto-form is to get detailed feedback from folks on whether we've Got It All Wrong :)
(disclaimer: Matrix is all my fault)
As for the huge number of RFCs: Well, those do cover a whole lot more than passing blobs around? That aspect is fully covered by the SIP RFC, and only a relatively small part of it, the rest is concerned with session establishment and teardown, which HTTP obviously isn't concerned with at all.
Which is why I am wondering: What is the point of using HTTP? What is the functionality that it provides you with that would justify requiring an HTTP stack in every endpoint, including the security risk from all that complexity?
As for RESTfulness: REST is in conflict with a fixed URI scheme, REST allows only for a fixed entry point, beyond that, all other relevant URIs should be discoverable from the returned representations. And no, I am not saying, your stuff should be RESTful, I'm just saying that it's not.