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.

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