I'm curious what the author's loose definition of "API" is, if all of those API's that were presented were somehow not API's to the author (strictly speaking, they were definitely all API's).
Reading through the article, though, the author isn't advocating for "no APIs," they're advocating for minimalist APIs that use agent detection to "do the right thing."
Chrome tells the API that it can accept HTML, so the server sends data formatted inside of a web page, with an HTML table.
Curl doesn't send that header, so the server sends unformatted CSV. But you could send an Accept header to get the HTML if you wanted.
The benefit of this is that for most use cases, this will "just work."
The downside is, if you want to view the CSV in a browser, or the web page in curl, you need to know (or guess) how the server is deciding what to send you, and take the correct action. An API documented with OpenAPI, while more complicated, explicitly tells you what you can do.
I've long held that software ages far better if you just eliminate the ability of people to provide it input.
That's what the author is saying they don't have. When you import their client library you just have a new URI scheme you can use anywhere that accepts a URI, not layers of extra classes and methods to learn how to interact with.