Don't Introduce a V2 API

This is reasonable advice early on, when you only have a reasonable number of warts in your API and are still able to move rapidly. However, as you go, maintaining every API in a fully-backwards-compatible-forever environment will eventually create sufficient cruft that you as the API developer can no longer build new things quickly (or, eventually, at all), which means that eventually you are unable to keep your technology and feature set growing enough to stay relevant in the marketplace because you have an increasingly enormous investment in your historical support story.

At which point you eventually start losing your current customers too because they can do enough things with the new, fast-evolving API of your competitor that it's worth the cost of rebuilding.

This needs to add a caveat. Current users will almost certainly prefer the older API. Newer ones are more likely to be hesitant about dealing with a tangled mess.

Also, most documentation of APIs is nowhere near good, so intuition matters a lot.

If you can't continue to provide and maintain the v1 API backend because its approach and assumptions were chosen badly, that's also a way to fail.

HN is full of 100% black or 100% white theses that are the equivalent of guerning youtuber clickbait. Most of it is true under some conditions and false under others... it would be better to put it that "Sometimes you have to pick if v1 or v2 of your api is more likely to kill your project".