The HTTP 1.1 to 2 upgrade is only going fine due to massive work (mostly by Google) over a period of years. HTTP/2 was also able to benefit from a lot of pain that SPDY and WebSockets went through earlier. Protocol ossification is still a hard problem.

This is one of the major reasons HTTP 2 is only supported via TLS and only via a complex upgrade protocol.

It's not that you can just do "GET / HTTP/2.0" or something like that.

The TLS part is interesting, as wrapping a protocol into an encrypted channel solves a lot of these issues (but it can break again if you have stupid man in the middle boxes). It just doesn't solve the issue for TLS itself.

The main difference is that a "side channel" of the TLS connection (the NPN or ALPN extensions) is used to negotiate HTTP/2. The upgrade to version 2 without the TLS wrapper failed; so many servers and/or middleboxes had issues with it, that all browser makers decided "HTTP/2 is going to be TLS only" (the current "encrypt all the things" push played a small part, but the main reason was the compatibility problems).

Clients can fall back, and falling back to HTTP/1.1 isn't a security problem the way falling back to, say, TLSv1.1 is.

Because it's up to the client to request HTTP 2 if they support it. https://http2.github.io/http2-spec/#discover-http