[1] https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc...
That said, JSON is just an encoding format. The actual response format is not "JSON", but the specific structure that your clients are expecting to receive (even if it is encoded in JSON), and that can certainly have links.
"REST good. I want." That's as far as some thinking goes :-(
IHMO ,The problem is nobody has a clue what REST or RESTful really means,at least I don't. But it's clearly not a protocol. It's not even a well defined pattern that exposes clear behaviors with rules. Some developers don't like that, they want clear goals to do their work and want canonical examples they can point to when arguing with colleagues.
So personally I understand the appeal for RPC : No semantics , no arguing about whether one should use PUT, POST or PATCH and when , whether links should be headers or in the body, or about which JSON/XML bloated spec to use to make an API HATEOAS...
That said, it's true that REST by itself doesn't tell you how to build an API. But all of that arguing about PUT/POST/PATCH, links here or there, etc, are mostly bikeshedding. It's like arguing for tabs vs spaces or whether the { should go inline or not. Just read the HTTP spec and then, when in doubt, just pick one and try to be consistent.
But you're right that many programmers don't deal well with that. It'd be nice to have some kind of reference protocol using HTTP & JSON and complying with REST, even if it would be as arbitrary as any other possible RESTful protocol.
During the my first job interview with them, they asked, "Do you know how to work with a RESTful interface?" I said yes, and I told them to look at my Github account for examples.
During my second job interview with them, they asked "What do you consider when you are designing a RESTful interface?" I quoted a bit from the book that Sam Ruby and Leonard Richardson wrote, back in 2007, and which I've read cover to cover. Among other things, I said the overall goal should be to work with HTTP, not against it. Then their lead programmer tried to ask me what he apparently thought was a "trick" question. (He was quitting the startup to go back to school, and I was being hired to replace him.) He asked, if, for a given task, HTTP was too verbose a protocol, then what else might I use for a RESTful interface. I suppose that should have been my first warning. I wasn't sure what they were looking for, but I thought maybe they wanted me to say WebSockets, or perhaps they wanted me to push back against the question and ask why HTTP was too verbose, or they wanted me to suggest the use of TCP in an ad-hoc style that mimicked HTTP. I explored all those possible answers as I spoke with them.
Then I was hired and I started the job. Their system is not RESTful at all. The only HTTP verb they use is POST. They use it for everything, and they put all their data in the body of the POST. Their system is pure RPC, with a style influenced by SOAP.
The people I'm working with are in their early to mid 20s. I'm not sure if age is a factor, since I've seen the same mistake made by programmers in their 50s. But, for sure, there are some programmers who do not seem to know the difference between RPC and RESTful.
Of course, on a personal level, none of that really matters. I really like this place that I'm now working, and I'm happy to work with their RPC style. I have, however, insisted that we use correct terminology, just for the sake of clarity.