This is exactly the point we're leading to - if you need vast heterogenous support everywhere, you're doomed to use TLS/SSL and you'd better cook it well, cause it has plenty of problems.
But, from our point of view, most non-web-developers (mobile? distributed applications? there are plenty), who now use SSL, but can afford themselves either avoid HTTP at all, or implement decent cryptographic stack on top of it, because they control both client and server, and don't need multitude of platforms to talk in the same way.
That's the point we're leading to in this article.
I guess I was thinking mobile using a home/corporate wifi network, which means you're back to (possibly) dealing with proxies, etc. Even if you control client and server, your protocol has to work over the network you are running on. Today that's HTTP based.
Well, network is TCP/IP based last time I've checked, but yes, most people today tend to organize such communications over HTTP for simplicity (although it's not that good at all), I get your point.
