The 2.0 in HTTP2 is just a semver version—it's 2 because it's not wire-compatible with 1. In terms of features, it's pretty much 1.2.
And besides, "serving static resources slightly faster" was enough to get a lot of big corporate players excited to switch. It might not excite you as a developer because it's "just" an infrastructure-level solution to an ops-time scaling problem, rather than a change in development-time workflows. But ops-time scaling problems are real problems, and Internet wire protocols change in response to those problems more than they ever do in response to developers' concerns. (There's a reason all current wire protocol standards are handled by the IETF—a body of data-center and NOC ops people, basically—rather than by developer-oriented groups like Khronos or WHATWG.)
Also, "slightly" is an understatement on severely latency-constrained links, like those of cellular or satellite internet connections, or over Tor(!). If you can turn 10 (tiny) HTTP requests into one request with 10 (tiny) responses, you can often turn five minutes' load time into 20-30 seconds.