And yet, when I look at "everything over HTTP" (with occassional divergence to gRPC), it seems like most of it is crudely building missing layers of session and presentation.
Instead of reusing simple common blocks, we have tons of badly written textual parsers mired in historical details of early ASCII teletypes because the ARPA idea of protocol analyser was apparently "connect a teletype".
Many things are done over HTTP not for any particular reason of HTTP features, but because HTTP is the most accepted protocol across secured networks, and the fact that you'll easily find a package for HTTP support in almost any language you care for. HTTP is also the ultimate in portable GUI, so often you'll have an HTTP server for your product anyway, so using any other protocol besides it will add more problems.
If you try to use a new protocol over TCP, you'll quickly find all sorts of corportate networks that will drop your traffic; you'll quickly find that people are reluctant to open several ports to allow both your Web GUI and your backend protocol to talk to each other.
So at a very basic level, people aren't piggybacking over HTTP itself, they are piggy-backing onto "Most Used GUI protocol". It's true that they sometimes adopt some of HTTP's features, especially in terms of caching or common error formats, but much more often they ignore it completely (with WebSockets) or partially (binary data in POST requests with custom error messages).
Just as HATEOAS and Content-Type negotiation are extremely rarely used in application protocols, I don't think a Presentation layer would have ever caught on realistically speaking.
Instead of reusing simple common blocks, we have tons of badly written textual parsers mired in historical details of early ASCII teletypes because the ARPA idea of protocol analyser was apparently "connect a teletype".