Re: Hope it gets adopted really fast
CDNs are where POST may very well cause performance/caching/etc. issues. This is not the only use case, and it was never my use case.
Let's say you have a system with distributed clients (not humans, call them "agents" since it is such a common word nowadays, but no relation to LLMs) and a server, with a DB, business logic, and a GUI - not a web server as you probably imagine. What you want is an API layer that will a) facilitate the agents' operation, b) sit behind the GUI allowing humans to get information, configure stuff, and perform actions manually, c) sit behind one or more SDKs to allow fun things like programmatic access to information, configuration, and actions, and to facilitate orchestration, 3rd part integrations, etc. I am sure you can see how the API layer is useful within such a system, but will probably not be used by 3rd parties as raw HTTP.
You can also guess that some of the API calls would be idempotent and could, in principle, be implemented with GET, while others would require POST. The payloads in all cases are quite complex and require an additional in-payload protocol. That can be, e.g., JSON (other options are possible, of course), and it is reasonable to have the response use the same protocol. So, "give me this part of configuration" (for, say, a subset of agents) will be represented as JSON and the response will also be JSON. "Change this part of configuration" will have the new configuration in the response, etc. Easy for handling in an SDK, etc.
Having completely different ways to handle these is cumbersome. Converting JSON to a URL tail and back is worse. Having sensitive elements of the payload in a GET URL is unacceptable, especially in security contexts. And so on, and so forth. Hence, let's do everything uniformly (simple!) with POST. And no, put/get would not be "the first field".
If I understand the point of QUERY correctly it will be quite similar to POST and will not have the awkwardness and the problems associated with GET. In fact, all of the above would be perfectly doable (hopefully) with simply changing POST to QUERY where appropriate (hey! it's idempotent - you can cache it!).
As I said before, goo idea, IMHO.