The author is basically advocating moving application logic inside of the API. This is counter to the entire purpose of an API.
Moving application logic inside the API will indeed protect you from having problems where the API changes in ways that make it incompatible with the Application, but that's because the API is now part of your Application and you're just going to solve those same issues within the API.
An API which provides every relevant data field is not "a programmer's API", it's an actual API.
I could be wrong, but I don't think it's that black and white. I think the intention is to advocate thinking about user intent. If the user really does want/need a flexible API method, then I think that makes sense to actually provide that.
The first example he gave was a leaky abstraction tightly coupled to the underlying storage, not an API. An API should precisely contain application logic - but that doesn't mean that your app shouldn't permit parameters as per the second example (the article presented a false dichotomy).
Moving application logic inside the API will indeed protect you from having problems where the API changes in ways that make it incompatible with the Application, but that's because the API is now part of your Application and you're just going to solve those same issues within the API.
An API which provides every relevant data field is not "a programmer's API", it's an actual API.