I'm sorry, but you don't really understand REST. Structured URIs (like '/transfer/${id}/approval') are nice, but are completely unrelated to REST. In the real world they are often used in an anti-REST way, specified in advance instead of linked via hypermedia.
A design that uses only opaque UUIDs as names for resources and reveals them to the client via links in the responses is perfect REST. Clean-looking URIs are a distraction, except that they tend to be easier to preserve across software rewrites.
You introduce aspects orthogonal to the post argument which is why the post does not even attempt to address them and you seem to think the author doesn't grok them.
HTTP method + a Unique URI are the essence of the Uniform interface constraint of REST. They are very much a part of REST. How the real world uses them has no bearing on their validity. This has to be managed by better informing the real world not by questioning the very notion itself. Linking via hypermedia is an essence of the HATEOAS constraint of REST. Both are orthogonal yet complementary aspects of REST. A discussion can be had about one without necessarily talking about the other as this blog post does.
On the other hand transparency vs. opaqueness has nothing to do with REST API design per se. All REST recommends is that clients shouldn't design themselves to assume specific semantics into the URI substructure nor should the services guarantee them. However structured design URIs do not at all fall foul of REST from an API design perspective, and help both development and debugging substantially.
I suspect you've introduced both issues related to Client API usage and used them to question serverside API design. The issues are not incorrect but the level of abstraction at which you choose to address them is something I would differ with.
A design that uses only opaque UUIDs as names for resources and reveals them to the client via links in the responses is perfect REST. Clean-looking URIs are a distraction, except that they tend to be easier to preserve across software rewrites.