This is obviously a poor design choice
No, it isn't. The world wide web was catastrophically successful using GET and POST (well, and the occasional HEAD request).
A good essay to review here would be Fielding 2009: It is okay to use POST.
POST only becomes an issue when it is used in a situation for which some other method is ideally suited: e.g., retrieval of information that should be a representation of some resource (GET), complete replacement of a representation (PUT), or any of the other standardized methods that tell intermediaries something more valuable than "this may change something."
Limiting your API to GET and POST may be a poor choice, but it isn't an obviously poor choice.
I feel that this is a bit of a weak argument. Is there any stronger point I can make against this design?
The stronger point to make is that, if you use the http method that has the appropriate semantics, then general purpose components can take advantage of their own understanding of those semantics to do useful things.
For example, both PUT and DELETE have idempotent semantics. That means that a general purpose component can know to resend a request when there is no response to the initial request. We don't have to ask if that is okay, or know anything in particular about either the target resource or the payload.
So if you are doing something that is a fit for the semantics of those methods, then you get additional benefits "for free".
But do keep in mind that the value of those benefits, in your circumstances, may be small. The REST interface optimizes "for the common case of the Web".