The problem is that a new protocol that will be implemented by everybody and their brother in buggy ways will see a lot of debugging initially, and that's usually when my phone rings. Tools like wireshark will have plug-ins for the protocol, assuming it is implemented correctly those plug ins will show you what's going on at the HTTP2 level. But since that's with a high likelihood exactly where the bugs will be that part isn't going to work, which translates into digging through hexdumps for the foreseeable future trying to figure out why widget 'x' doesn't want to talk to device 'y' when the moon is full and the wind is from the west.

With a text based protocol you at least stand a fighting chance, I've done my share of slogging though dumps and I'm not looking forward to a repeat. One of the main reasons I suspect HTTP caught on as fast as it did was because people could actually look under the hood and understand the basics and figure out where things went wrong without resorting to dumping the the data and counting out which variable length header bit got it wrong this time.

HTTP isn't perfect, don't get me wrong (not specifying an end-of-line for the header with a single character was a mistake in my opinion, and there are a few quirks that make a much faster header parser impossible but that's minor stuff).

So, the telnet by hand case will still work, but that's not where the bugs will be, in fact, testing using 'telnet' will quite possible show you a situation inconsistent with the one using the newer version of the protocol. Having two delivery methods for the same data under the hood is a bad idea to begin with.