I think this is a fair point. REST is all about resources and representations, which makes modeling simple CRUD actions on domain objects very easy. However, modeling application processes effectively is harder and requires deeper thought and a more thorough understanding of REST.

I've always thought the key to understanding REST is understanding idempotence. Is HTTP request to mark an order as paid idempotent? If so, a PUT/PATCH should be fine. If not (say, you're actually transferring funds) then a POST should be used. This key principle will help make your URL design choices much easier. In your example, the PATCH API appears idempotent, making the suggested POST replacement sort of confusing to me.

When it comes to modeling application processes using HTTP, understanding which requests are repeatable without consequence and which aren't is very important. It's hard to talk about modeling processes RESTfully without talking about idempotence. It's at the heart of the protocol's design.

RESTful thinking needn't be harmful for application processes as long as you do it effectively.