That’s not how I read “Don't ever implement good-enough-for-now APIs”.

Requirements _may_ change, but it’s much harder to have consumers move to a new API. Once it’s published, it’s a contract you don’t want to break.

That doesn’t mean you need to design an extremely flexible and future-proof API to the point it stops making sense — it’s a false dichotomy.

What you can do is take your time designing an API that still makes sense as long as possible, until your understanding of the domain has changed so much that it’s a different shape altogether.

Throwing your hands up and saying “it’s impossible” is easy, the art is in figuring out how much has to change until you have to say that.

Design is a game of push-pull between context and form, and you can add tolerances both ways.