Why does the Fetch standard forbid GET Body when it's not against REST?

[nickwelp]

The REST standard, updated 2014, RFC 7231 https://www.rfc-editor.org/rfc/rfc7231 ; basically the 2014 spec for REST says that a body for a GET statement should not be predefined by software operating it, and not excluded. "A payload within a GET request message has no defined semantics." There is a decent Stackoverflow thread about it here: https://stackoverflow.com/a/983458

Why do the Fetch specs then forbid it? https://fetch.spec.whatwg.org/#dom-request
35. If either body exists and is non-null or inputBody is non-null, and request’s method is GET or HEAD, then throw a TypeError.

I realize it's easily accomplished, encoding json into URL parameters. However I'd like to understand the appetite for divergence on this issue.

[gibson042]

Duplicate of #551, which references httpwg/http-core#202 that ultimately affected text in the successor of RFC 7231: RFC 9110 section 9.3.1 (emphasis mine)

content received in a GET request has no generally defined semantics, cannot alter the meaning or target of the request, and might lead some implementations to reject the request and close the connection because of its potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A client SHOULD NOT generate content in a GET request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported. An origin server SHOULD NOT rely on private agreements to receive content, since participants in HTTP communication are often unaware of intermediaries along the request chain.