did you even read the article? it describes why this is a bad idea — it’s not just your server that’s handling the request, it’s all the other middleboxes in between.

With POST, you can't know at a system level if it's safe to cache the response or not.

Cache-Control response headers?

insufficient

> A cached POST response can be reused to satisfy a later GET or HEAD request. In contrast, a POST request cannot be satisfied by a cached POST response because POST is potentially unsafe; see Section 4 of [CACHING].

So if you are using POST to query, you can't cache the response. You have to resort to POST/GET. With QUERY, you have idempotent requests with cacheable responses you can directly return.

Cache-Control and Content -Location.

HTTP defines the POST method explicitly as non-idempotent

It's definitely not a "tremendous" amount of work. At the bare minimum, you copy your POST code and change the verb, that's it. There's no need to cache, so you actually can handle it basically as idempotent POST.

> You can just handle your POST request idempotently

You actually can't though, and you don't usually have to look far to run into a case where this gives the wrong behavior. Better to just have a separate verb.

Idempotency and safety is about how to send POST requests, rather than how to handle them.

You can't pre-fetch a POST request, or re-try after a timeout. Because you have to consider that the POST request could have unintended consequences if sent too many times.

That looks more of a documentation problem, rather than an HTTP problem.

You just document that that POST endpoint doesn't actually modify data.

A great example of this are OpenAI completions.