That isn't even a use case for REST. I think the writer needs to consider taht http APIs cover many different use cases with subtle differences. REST exists to solve the problem for one of those use cases, i.e. data model interactions over HTTP. But HTTP APIs can also implement function calls. Trying to emulate a function call, using REST is a terrible idea, and the blame lies with the developer that thought it would be a good idea. Not with REST.
Consider the logout operation. This a valid function call. But not using REST or any of it's principles. It's just a valid use case for HTTP. Now consider API methods that deal with a users profile information. Such as creating the user profile entry and later, maybe updating the address or status of the user. This would be a perfect example use case of REST.
TL;DR I think the author fails to understand that REST isn't and doesn't try to be a solution for every possible use case of an HTTP API. It's simply a framework for structuring APIs that directly, or almost directly interact with the models exposed by a webservice.
Now, onto RPC. RPC, is binary protocol over TCP. It's not even HTTP. RPC vs HTTP is a very valid argument depending on the use case/constraints for the project. But RPC vs REST is comparing two very different things. REST, IMO, derives most of it's flexibility from being built over HTTP, and not because REST is some kind of magic sauce that it's touted by many to be.