Strangely, very few people (at least that I've spoken to) who are fans of REST seem to have even picked up on the HATEOAS principles. I'm guessing that their fandom is more predicated on a hatred of SOAP/XML and love of the simplicity of JSON -- which is kind of strange since HATEOAS also works beautifully for Content-type=XML over HTTP.
EDIT: An attempt to formalize the Richardson Maturity Model (L3) for REST+JSON/HTTP can be found at: http://stateless.co/hal_specification.html (I'm not affiliated with it in any way, just thought it was interesting.)
REST isn't a technology, it's an architectural style. Regarding its benefits, they are all well specified in Fielding's thesis. REST is composed of a few constraints, and abiding by each one gives you certain benefits.
That said, I agree with you vis-à-vis the need to avoid blinders. In my opinion, there's nothing wrong with using RPC if that's the most adequate solution. What bothers me are all those new RPC-over-HTTP which people insist on calling RESTful.
And drawbacks.
HTTPs ubiquity, for better or worse, makes it about the only option for any web based tool where control from end-to-end isn't a practical option. Better protocols can be made, better hardware and software can be made to utilize them, and some have, but their reach is very limited for now. Understanding the thing we're stuck with is pretty important. Luckily, countless man hours have gone into studying the protocol and building the tools that take advantage of it. Much of that information has been shared openly. I think that's a pretty big advantage over anything else.
Specifically, your arguments rest on the vague and indefinable quality of "enlightenment." I think that this use of "enlightenment" means something along the lines of "I got something to work within a thought framework that appeals to me." But if he had started with a different framework (like RPC), he could have gotten that to work too, and perhaps would be feeling the "RPC enlightenment" because all of these problems can be solved within RPC too.
No one is arguing that HTTP-based APIs can only do CRUD. You can tunnel basically anything over HTTP, because ultimately the payload is just bytes. But the question is what using HTTP (and/or REST) has actually bought you, compared to competing approaches.
Graydon Hoare (one of the original authors of Rust) wrote an essay about this a while ago that I really love. Unfortunately he took it off the net, but it's still available on the wayback machine: http://web.archive.org/web/20040308200432/http://www.venge.n...
The essay is written in a very whimsical and wandering style, but the point is dead on:
HTTP/REST and XML inhabit slightly different design spaces, so for HTTP/REST some of the external measurements might be a bit different. But if you are trying to argue that REST is better than competing technologies, the question is: what objective benefits does it offer, compared to those other technologies?Clearly there are benefits to REST/HTTP (being able to use a web browser as an ad-hoc UI in many cases is one), but the idea of "enlightenment" should not be a substitute for an actual compare/contrast of approaches.
So yes, of course the author could find a solution to his problems that still used HTTP. The question is: once he does this, is he better off than if he had chosen a competing technology? (imagining a world where you aren't effectively forced to use HTTP to make it through firewalls).