Alright, think of it this way.

People use HTTP for two things these days:

1. Its originally-stated purpose--an application-layer protocol that allows web browsers to retrive hypermedia documents from web servers. In this usage, HTTP replaced Gopher+FTP.

2. A transport-layer protocol, with features such as identified sub-flows (requests in a pipelined keepalive connection, websockets, etc.), several usefully-different varieties of caching, protocol feature autonegotiation, presentation-layer autonegotiation (Accept headers), automatic redirection semantics, optional encryption (TLS+HSTS+CORS = probably the most well-thought-out security-boundary semantics of any protocol we've got), etc. In this usage, HTTP basically supercedes TCP.

There's a vicious circle here: as HTTP gains traction in sense #2, businesses become increasingly unwilling to allow anything other than HTTP-in-sense-#2 through their firewalls. Eventually, HTTP may be the only transport-layer protocol.

And, given that, on a stance of complete pragmatism where we can't prevent this from happening, only try to make the best of the situation... we need an HTTP-in-sense-#2 that can actually support being used as a universal transport-layer protocol for all of the Internet's traffic.

What does that mean? Well, it means, for one thing, making HTTP lower-overhead (i.e. binary.) It means making HTTP not only work in situations we'd previously have used TCP (e.g. websockets), but also situations where we'd have used UDP (e.g. VoIP streaming.) It means, well, doing pretty much everything HTTP2 does.

Note, though, that HTTP in sense #1 will likely always be around. Nobody who uses HTTP to transfer hypermedia documents between web browsers and web servers needs to switch to HTTP2. HTTP2 can do that, but it isn't for that. (Though, practically, doing HTTP-type stuff over HTTP2 will likely be both faster and more secure.)