Great article. Thanks for sharing it!

To me this raises the important distinction between REST, which was intended to enable state changes in server-based resources (or "entity" data), and Remote Procedure Calls (RPCs), which you very correctly differentiate.

As I see it, the issue is whether and how to apply the REST style to initiate processes that then affect these state changes in addition to or in place of the more traditional REST-based CRUD operations.

One way to do this is to explicitly differentiate resource operations from process invocations in the path, e.g. GET [BASE_URL]/api/v1/resources/orders/{orderID} ... vs POST [BASE_URL]/api/v1/processes/orders/deliverOrder/{orderId} ...

To me, this is less about not using CRUD-style APIs, which as you point out still have a lot of valid, valuable uses, and more about cleanly, clearly differentiating resource operations from process invocations, i.e. more "yes, and" than "no, but".