Sounds to me like you're listing the benefits of the FIOH (as used in the article) style, i.e. using HTTP verbs to manipulate (reasonably named, nested) resources (which often, but not always, maps to CRUD actions on your database models), as opposed to the RPC style.
The main issue that we're doing FIOH and calling it REST, which makes internet arguments about RPC vs FIOH harder and confuses the hell out of newbies who are told to go and build a "REST API".
Agreed, "REST" as we generally use it is actually "RDD" or "ROA" (Resource Driven/Oriented Design). Use of HTTP as the protocol is a "side effect" that happens to map nicely. [1]
But it's more than that, especially if you design using resources, finite state machines and transitions. That's independent of protocols or anything else. Once you have that defined, the infrastructure often "falls out" and you have APIs that are reasonable, as well as working well into CQRS and Event Sourced implementations.
A lot of this stuff was thrashed out on that yahoo group, which happened around the same time as "AJAX" became the latest buzzword.
I think of RPC as "The verb is important, not the noun", whereas REST/ROA is "The noun is important, not the verb".
The main issue that we're doing FIOH and calling it REST, which makes internet arguments about RPC vs FIOH harder and confuses the hell out of newbies who are told to go and build a "REST API".