The long and the short of the document was that a REST client must be able to navigate the entire API when given just a single endpoint URL, much like you can navigate an entire website just by entering the homepage URL into your browser, but without the dependance on HTML.
The leap the document made, and what virmundi seems to be referring to, is that a REST client that speaks, say, JSON is not enough to traverse any random service, as everyone will provide a completely different JSON representation of their data. When you start hardcoding site-specific keys in which to find the action descriptions, you lose all of the flexibility the author claimed REST would provide in the first place.
I've downloaded the original thesis. I'll look there to see what's mentioned about the hypermedia linking process.
Or define link semantics in JSON, the one documentation a restful service should have is that of media types (the documents returned) anyway, the only URL which should appear in the documentation is the root of the service.
Whining that JSON has no link semantics is nonsensical, SGML does not have any either, HTML added those when it was first created as an application of SGML, just as text/xhtml+xml is an application of XML defining links, "XML" as a meta-type does not know about links either.
Then use HTML. Or some other representation with known link semantics.
I don't see how failures or shortcomings of JSON indicate a problem with REST. They are orthogonal; JSON has nothing to do with REST, it's just a serialization format some people like.