I don't have strong feelings about this article except for the fact that it once again uses REST to mean "JSON over HTTP" when, in fact, REST requires HATEOAS and the vast majority of APIs that claim to be RESTful aren't, and almost certainly shouldn't be, since they aren't using a hypermedia/hypertext.
The API community made a mistake in appropriating the terms and concepts from REST (a description of the original web architecture) and we've been unwinding that mistake for almost two decades now, but the momentum of language is amazing...
Yes, true pure technical REST probably does require HATEOAS. However, there's still a lot of value in a "RESTful" API that that achieves at least 'Level 2' in the so-called Richardson Maturity Model.
On my teams I advocate for building Level 2 maturity "RESTfulness" into the design as it seems to strike a good balance between following the principal of least surprise for those who need to consume it and the heavier implementation effort required to get to that Level 3, which as you point out is probably not even appropriate in most cases.
Seriously, give it up. It's a losing battle. The term means something different from what you want to to mean. How many HN comments about it are we going to have to suffer through?
https://intercoolerjs.org/2016/01/18/rescuing-rest.html
https://intercoolerjs.org/2016/02/17/api-churn-vs-security.h...
The API community made a mistake in appropriating the terms and concepts from REST (a description of the original web architecture) and we've been unwinding that mistake for almost two decades now, but the momentum of language is amazing...