I still don't get the need for QUERY. One can create a search or filter resource with a POST request and then query it using GET. As a bonus, creating a resource allows it to be shared and cached.
Right, that process works today just fine, but that's application code that the browser (and middleboxes) can't assume. The idea is that QUERY directly represents that flow to the browser as a direct participant (and to caching middleboxes as well). A QUERY can (optionally) create a search or filter resource and return a Location: response header that points to a GET resource to refresh the next time the same QUERY is asked. The browser can directly cache that Location and associate it with that QUERY body. (So can middleboxes.)
A POST can return Content-Location: to the GET resource, but the browser can't assume that the same POST body contents create the same result Content-Location, whereas the QUERY Location represents the QUERY itself as a repeatable object. (Also, QUERY can return Content-Location instead of or in addition to Location for subtly different caching implications.)
Obviously the approach you mentioned has the downside of two server round-trips being necessary while the QUERY request only requires a single round-trip. Not to mention the two-request approach adds more complexity to both clients and servers, as it mandates that both the client and server have to physically create and manage those resources.
Because HTTP is stateless by definition, you now need to support persistence (state) on the server side whenever you want to run a slightly different query, which contradicts the preamble.
I understand the confusion around GraphQL's cached/persisted queries, but this is not the intention of HTTP.
