> RESTful APIs are dominant currently.
That depends how you define RESTful. One's conforming to the architectural style Fielding described are quite rare.
> However, it seems to me that elements of the REST "style" are constricting for no reason.
While there may be debates over the merits of the reasons, nothing in REST is without a reason.
> I see how conforming to the original intention of the HTTP methods may be elegant or in some way natural, but I can't summon any kind of compelling justification for a restriction to only GET, PUT, POST, DELETE
REST does not impose such a restriction. Heck, REST is a big reason for PATCH and the proposed SEARCH method. OTOH, I think with PATCH and SEARCH added, the standard HTTP methods provide a pretty complete set of operations.
OTOH, while HTTP itself is a REST API, REST is not in anyway tied to HTTP or it's set of methods.
> Using GET forces parameters to be placed in the URL; wouldn't it be nice to deal with only POST requests with JSON bodies?
No, it would be better to have SEARCH, which is safe but takes a request body. Also, you literally just went 180° from complaining about being limited to only four standard methods to arguing that it would be better to have just one standard method. Without actually explaining either of those diametrically-opposed complaints.
> Web APIs are almost always accessed programmatically anyway.
Fielding-style REST (which, to be fair, most “REST” APIs are not) is pretty optimal for programmatic access, since it is fully self-describing and discoverable, given that the client has handlers for th involved media types used for resource representation.