Definitely not performance, QUERY is an improvement/hackfix. Browsers have a cap on size of the request headline path (used to be very small for IE7), and server software also tend to cap the size of it, as a security mitigation (smth like max header size, similar to what happens with cookies). For this reason, technologies such as elasticsearch or graphql, which allow for quite large query defs, use POST and fit the query in the body instead, which is not bound to the same limitations.
Semantically, such queries are cacheable, but the request being POST, intermediate edge proxies or CDNs won't cache the request. This means clients pay the penalty every single time. Moreover, browsers can't have url-based history with such solutions, as POST requests can't "go back".
So QUERY fixes this. Semantically. Now you have to build support in middle boxes for it, and browsers must support it as well.
As far as I know, GET and DELETE requests support a payload body as per one of the later specs, whereas an earlier version wasn't fully clear on this and people assumed it's forbidden. Unfortunately, there's still a lot of software conforming to the interpretation of the old spec, which means you cannot count on these HTTP verbs to be supported.
Given this legacy, QUERY seems like an adequate solution. However, it seems to me like it's only intended for read queries. Write queries are generally not cacheable semantically, at least not in my world. Was the naming influenced by GraphQL by any chance, which distinguishes between queries (read) and mutations (write)?
Semantically, such queries are cacheable, but the request being POST, intermediate edge proxies or CDNs won't cache the request. This means clients pay the penalty every single time. Moreover, browsers can't have url-based history with such solutions, as POST requests can't "go back".
So QUERY fixes this. Semantically. Now you have to build support in middle boxes for it, and browsers must support it as well.