It may amuse you to know that your "new non-HTTP protocol" is basically describing SPDY, Google's new alternative-to-HTTP protocol, which is live and works in Chrome and e.g. any netty-powered webserver.
Look the counterfactual: any protocol (including HTTP...or TCP...or IP...) has "no advantages" unless both endpoints can understand it and the network can transmit it at the most appropriate layer. Until then, it requires tunnelling. That was definitely the case for the first rollout of TCP/IP, or HTTP.
It definitely doesn't imply that it shouldn't be done--the only thing that it implies is that it's harder work for the adopters until it has a critical mass of mind share and then it becomes harder for the non-adopters. If the alternative to that is no, or only centralized, improvements to protocols, I'll take the breakages.
I specifically thought of SPDY when I used that example; in fact, that's what makes it such a great example: SPDY asked themselves this question, and had a really great answer for it (specifically, that HTTP is used first, and only if the server opts in to using SPDY does it upgrade to a faster protocol, saving that information for later use).
The saddest part here is that I agree with you: I like that Rails decided to do this, and for the very reasons you describe. However, I expressed disappointment that this announcement/article decided to ask "will my web server support this" and didn't bother to ask "will the client be able to route to me with this".
Remember: I myself believed it would work, and even provided multiple reasons in my post for why it would. However, it would have been nice to see these points brought up in the article. If my version of nginx doesn't support it, I'll just upgrade, but if I'm honestly concerned about support, I'm going to care if I can even trust a PATCH to my client code.
Look the counterfactual: any protocol (including HTTP...or TCP...or IP...) has "no advantages" unless both endpoints can understand it and the network can transmit it at the most appropriate layer. Until then, it requires tunnelling. That was definitely the case for the first rollout of TCP/IP, or HTTP.
It definitely doesn't imply that it shouldn't be done--the only thing that it implies is that it's harder work for the adopters until it has a critical mass of mind share and then it becomes harder for the non-adopters. If the alternative to that is no, or only centralized, improvements to protocols, I'll take the breakages.