The HATEOAS idea is that you throw that out, just use some aribitrary XML (sorry, "hypermedia") to return your application state, and that this somehow magically empowers the client to be able to puzzle out all the things that can be done to your state.
Except it can't. It's just arbitrary junk if you don't have a schema and a spec. And it will always be so. Discoverability is (1) not something you can get from a data structure and (2) something best provided by documentation, not runtime behavior.
(One of the other problems with Fielding's work is precisely this word-salad of new jargon and usages, leading to exactly this kind of what-does-it-REALLY-mean-anyway confusion. But that's an argument for a different thread.)
As for Fielding's work having a word-salad of new jargon and uses, I frankly didn't get that by reading his dissertation, which I found quite clear. There are a few concepts (Resources, Representations), but I think they make sense in the context.
I think REST/HATEOAS purists have always overplayed the browser example.
Pure machine to machine interaction is hard to automate.
you get some html with embedded links and then the browser automatically goes and fetches css, js, images...
the remaining links it just presents to you, the user, to follow or not as you choose
hateoas is not a complicated idea. it's not meant to replace SOAP or gRPC or thrift. it's something else