Because nobody uses them and supporting them can cause more problems than they are worth.
The author was ranting about unused features, but not all features are good ideas. Sometimes things that look good on paper don't work so well in practice.
> Because nobody uses them and supporting them can cause more problems than they are worth.
Can you substantiate that? Why shouldn't I be able to POST a new resource to a server and update an existing resource with PUT using Forms? Why shouldn't I be able to delete a resource using a DELETE method using a Form?
REST-the-actual-paper is a monstrosity that, thankfully, no-one actually uses. "REST" as a name for the practice of using simple JSON and using existing HTTP features (methods, status codes) rather than using HTTP as a dumb transport layer is... an ok idea, but overhyped. The supported HTTP vocabulary is very limited, and adding new verbs like PATCH is a multi-year process that's never going to be well supported by every existing piece of software. So sooner or later you're going to have to layer a more complicated (business-specific) semantics over HTTP, and have e.g. a POST that actually has semantic meaning beyond being a POST. Given that, if you just used POST for everything, and had a simple encoding of method kinds and error responses over that... would that be so bad?
Those who forget SOAP are doomed to recreate it, badly. I worry that things like JSON-schema are headed in that direction.
Absolutely. If you ever used a web browser (one that understands HTTP and HTML), clicked a link on any website, or submitted a form, you've most likely benefited from REST. Here's an example: https://news.ycombinator.com
* Until recently, used stateful numbers for all links
* Uses the same location for different resources (e.g. https://news.ycombinator.com/item)
* Serves the same resources at multiple different locations, rather than redirecting you to a canonical location.
* Does posting, editing and deleting via POST, not CREATE/PATCH/DELETE
* Does approximately no content negotiation
* Does not support non-browser clients at all, which, well I suppose you could make a perverse argument that that is HATEOAS.
In short, it behaves not at all like the system described in the REST paper.
HTML is a hypermedia format. REST is an architectural style that requires hypermedia in order to work. Hypermedia formats have factors (http://amundsen.com/hypermedia/hfactor/) that make them more suitable for some use cases and less suitable for others. HTML alone does not have idempotent updates (PUT, DELETE), but as REST allows for "Code-On-Demand", we can augment the user experience with Javascript, and it allows PUT/DELETE (with XMLHttpRequest).
HTML is designed for REST. Which is why a form does not support arbitrary HTTP methods, but only the methods which semantically makes sense for a form.
The author was ranting about unused features, but not all features are good ideas. Sometimes things that look good on paper don't work so well in practice.