Do you really believe if you don't use Accept headers as the only means of version that you aren't REST? Is REST a pattern you can follow only to the letter of Roy Fielding's dissertation? If so there might not be ANY REST web services out in the real market that are big. Everyone is just doing RESTish or RESTy instead of certified RESTful.
Also I believe HN is a place where we can discuss articles and pragmatic opinions about it, I don't assume everyone just agrees that this presentation was the one and only way to do REST like the author was stating. I stated my opinion to that. If this is the only way to do REST, simple services then the whole web isn't doing it yet.
This turned out like a rag on REST which it is not. It is a rag on over complicating and ivory tower architecture. REST should be about simplifying web services for consumers as well. When you get to implementing your RESTful service to support all clients, even with the current marke,t you will find it doesn't fit everywhere.
A service should be liberal in what it accepts and conservative in what it sends. The market deems when it is necessary to tighten the standards, right now his interpretation of it is too narrow.
We need a new standard called SIMPLE: RESTish/RPC, HTTP based, simple messaging (JSON/YAML), urls can be abstractions (in fact it is better to hide your models in most cases except for an admin scaffold), consumer aspect based routing (login, signup, myinfo) all the way from front end to service abstraction. Accept and formats can be in headers first and fall back to url based. Kinda like how systems like twitter, facbeook, 37 signals, etc do.
I agree we need a good word for those HTTP-but-not-quite-REST APIs. I simply call them "HTTP APIs", but maybe SIMPLE, NoRPC or REST 2.0 will take off ;)
It even quotes Roy saying "Many of the constraints are directly opposed to short-term efficiency" and that most developers don't care about goals of rest.
I think points you're making are fine, but they're acknowledged in the presentation, so your rant is unnecessary.
I think the author did a good job presenting actual (you can say academic) REST, rather than a more popular and simpler to create "JSON-over-HTTP database" pattern (which is fine, but shouldn't technically be called "RESTful").