The article brings up interesting points, but reads like I'm blasting through a red bull ad. (Zing Zang Zoom!) API development is super important, and KIS principles should apply, but i felt this post was more marketing and less functional advice.
Literally all API design articles are marketing. There’s almost zero, aside from foundations that came from academia, early industrial or military specs, or very shallow blog posts that are almost useless when you actually build something beyond a prototype.
I found it surprising because I interacted with their REST APIs first. They are very good about docs. The ones I use most frequently (TS) are no exception, though they have some gaps. But the actual REST APIs I integrated very clearly predate a lot of their guidelines or struggle to follow them.
Comments were very insightful as always. I kind of agree with OP, this article is very thin on content and mostly peripheral take on good API design. It is unhelpful.
Don't add GraphQL without understanding what you're getting into. I wouldn't use it in the same 'latest frictionless' context that the article mentions.
You should never add something coming from Facebook without quite some hesitation. Their mantra "move fast and break things" broke more things than they could have imagined. GraphQL isn't great, it isn't even average. It's actually pretty terrible. It's just another query language and actually you don't need it. Steer clear from it.
The best API's fit how users actually use them. I'm not sure there is a one-design-fits-all. One has to study to see what's done the most often and optimize around those, yet still allow flexibility for the times that deviate from common usage patterns. Make the common stuff short and easy, but the uncommon stuff possible and clear-cut. It may take a couple of iterations in actual use to tune it.
I also like "self-eating dogfood" in that the shortcuts are defined using existing "long-cuts" and the API user can study, learn from, and change and/or write their own shortcuts using the long-cuts.
C#'s optional-named-parameters (ONP) are ideal for such. I don't why Java and JavaScript don't implement ONP's. The alternatives, such as object literals and method overloading, are just too clunky. Once you tasted ONP's you don't wanna go back.
I'm not sure how I feel about the term API being used unqualified to refer exclusively to SaaS remote APIs. API design is really important for any kind of library or module.