Entity Bodies in GET Requests?

I am reading RESTful Web Services, which nowadays is the book about the pure-REST, resource-oriented approach to Web Services.

The authors explain that albeit HTTP has no restriction about the length of the path of a GET request real web servers do have limits on what they accept. So, if you are designing an interface and some resource can have large scope data you need to take that into account. The proposed workaround is to forget purity and switch to POST.

HTTP/1.1 says about message-bodies:

The presence of a message-body in a request is signaled by the inclusion of a Content-Length or Transfer-Encoding header field in the request's message-headers. A message-body MUST NOT be included in a request if the specification of the request method (section 5.1.1) does not allow sending an entity-body in requests. A server SHOULD read and forward a message-body on any request; if the request method does not include defined semantics for an entity- body, then the message-body SHOULD be ignored when handling the request.

If you read section 5.1.1, and you follow to section 9.3 to read about GET, nothing is said about message-bodies. Hence, message-bodies are allowed in GET requests. In addition, if your web service documents the semantics of what expects in the message-body (scope data in such XML vocabulary, an image in such format) my interpretation is that all things are set up in a way that allows entity-bodies in GET requests.

Of course the authors of RESTful Web Services know their stuff, so I wonder why they recommend POST.

I guess the message-body of a GET method as per HTTP/1.1 has no defined semantics, and there's also this explicit mention to the path in section 9.3:

The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI.

which might imply everything needed to serve that request as far as the resource is concerned has to go there. Hmmmm....