Now we build a different tool, let's call it http2net. With HTTP being so prevalent, perhaps it isn't unreasonable to think it becomes part of most OS distributions.
So now you are using a tool (http2net) to view/interact with the new protocol and this is good because it is easy to read and use.
In summary, is binary vs text really the big problem here?
You'd think so, but while it's true we can mostly pretend telnet gives you a raw TCP connection, telnet intercepts some character sequences. It just doesn't interfere much with plain text.
My problem with the hypothetical "http2net" tool is that to this day I still have to deal with systems that doesn't have basic tools like tcpdump, curl or wget. But telnet, nc or some other way of getting a semi-raw tcp connection is pretty much always available.
So I have every expectation that it'd take 30+ years before this "http2net" tool would be available everywhere I'd want it.
Regardless of the issue of negotiated options, most telnet clients goes into a command mode if you enter an escape character, defaulting to ctrl+], unless you explicitly change it or tell it not to with a command line switch. This happens for me regardless of port.
tcpdump and strace also confirms what I thought I knew, namely that it also does LF => CR+LF conversion also when connecting to other ports.
EDIT: Here's a simple demonstration of how it is decidedly not 8-bit clean:
echo -e "test\035help" | telnet www.google.com 80
Confirm with tcpdump, or this way if you have strace installed:
echo -e "test\035help" | strace telnet www.google.com 80 2>&1 | grep sendto
echo -e "test\035help" | telnet -E www.google.com 80
(I was, in fact referring to telnet option negotiation which will not happen if not using the telnet port. Since the escape character for interactive use is so easily remedied, it did not occur to me to consider it a problem.)