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.)