CRUD in it's purest form is rarely a good choice for but a part of an API. I think "task-based" vs "CRUD" is wrong dichotomy though. First of all, I am looking at the API not from the formal point of view, but from domain point of view.

Does your API make sense for the domain you and API users are working with?

In case there is a non-trivial business domain layer behind your API - then CRUD API (and actually GraphQL as well - except for analytics) are not appropriate. The API should talk in terms of domain. In some cases CRUD is fine for some auxiliary business domain like content management. In most cases it's not.

However, if your API is for some generic subdomain, there may be nothing wrong with CRUD as a basis - for instance, SQL is pretty much "CRUD". Then the application business logic will be built on top of it - so user intentions will not be application's domain ones, but some lower-lever, nearer persistence layer or similar. (I simplified, of course)

Everyone who is interested for more behind what this article is about can take a look at the DDD (domain-driven design) - then there will be absolute clarity where CRUD belongs to.