[ume]

Not quite useless. POST tells the server to check for a body which I think is a reasonable indication of intent. But otherwise, yes, it’s all arbitrary and just vague hints to the server program as to what you might possibly be thinking of doing…

[Semaphor]

But then GET as well as everything else can have a body, so most servers would check anyway.

[jerf]

GET isn't really supposed to have a body:

"An HTTP GET request includes request header fields and no payload body and is therefore transmitted as a single HEADERS frame, followed by zero or more CONTINUATION frames containing the serialized block of request header fields."

https://www.rfc-editor.org/rfc/rfc7540#section-8.1.3 (HTTP/2.0)

"A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request."

https://www.rfc-editor.org/rfc/rfc7231#section-4.3.1 (HTTP/1.1)

I've never used one or spec'd one, I consider it unsafe.

This is, of course, what the specs say, and they don't even really agree; I am well aware of the non-trivial daylight between "what the specs say" and "what happens in the real world". I point this out not as a spec compliance maniac but as something people ought to know... it's not a great plan to expect GETs to be able to have bodies, just as I would not suggest sending a 404 response code that also has the "real data" in it for whatever reason. You're just asking for trouble, even if it might sometimes work.