By "REST verbs match up nicely", I meant REST verbs match up nicely with HTTP methods...(there are currently about 9 HTTP methods?). That's why it's not an additional abstraction, a POST is a POST. Compared to SOAP, which is where I came to it, it's tightly aligned with the transport. (People used to advocate for SOAP saying you could use it over SMTP...). If you are going to do a non-HTTP API, REST doesn't make a lot of sense.
Anyway, I was still annoyed by the limited verbs 10 years ago after using REST for five years at that point. I even blogged about it, as I started doing HATEOAS about that time, so I really feel your annoyance. I've just discovered over time that the verb/noun thing is just stylistic, not an actual technical concern. All of your verbs can be nouns.
I've also done plenty of SOAP back in the day. I independently invented the equivalent of SOAP in an API back in 1998 where my RPC API used only one method, which was basically a "call(command)" for sending XML data upstream and getting an XML response (C++ app). The request XML had the "name" of the "verb" as part of the request. Basically a "command pattern".
So what I do today is I use "REST APIs" (like in Java Spring, Axios/Ajax, etc.) but all my endpoints are named as "verbs" (not nouns), and the only HTTP verb I ever do is a "POST".
So everything boils down to this:
let myJsonReponse = api.doSomeVerb(myJsonRequest);
Anyway, I was still annoyed by the limited verbs 10 years ago after using REST for five years at that point. I even blogged about it, as I started doing HATEOAS about that time, so I really feel your annoyance. I've just discovered over time that the verb/noun thing is just stylistic, not an actual technical concern. All of your verbs can be nouns.