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.
1. you can use Server Push just as well to e.g. notice when JSON responses you're about to send out contain "hypermedia annotations" (i.e. "link" keys), and set up async self-subrequests to push the linked resources as well—then the backend can avoid ever having to think in terms of something like GraphQL's nested schemas, instead just answering queries for individual resources with fields and foreign key IDs; and the frontend can just dumbly consider responses to map directly to objects, instead of having to have a complex OSI-6 presentation layer that unpacks nested-schema messages into their resource-object equivalents. Suddenly HTTP PUT/PATCH has coherent semantics again, without losing any performance.
2. This is "a good problem to have"—and a good design decision on HTTP2's part, in my opinion. Most sites don't need HTTP2, and can stay HTTP1. While, if you realize that you need what HTTP2 provides, that need will probably be driven by an individual application you have (e.g. Google Search) that is at such huge scale that it has its own custom infrastructure driven by your scaling needs, of which "and supports HTTP2" will just be one more. (And this argument seems to hold water: according to https://www.searchdatalogy.com/blog/http2-on-top-sites/, a large percentage of the top bigcorps doing web traffic have switched.)