[8bithero]

This approach would also be a nightmare if you ever decided to refactor the frontend. You'd be forced to do double the work since failing to update your backend would probably result in nonsensical legacy naming... I'd also dread to think what would happen if you also used the backend to serve a mobile app. You'd end up spending 40% of your time trying to figure out what to name fields before eventually going full circle and reverting back to logical generic names :|

[rvnx]

And the moment your SaaS is growing, and your customers request access to your API:

Instead of just implementing ACLs/permissions on existing APIs you have to develop and maintain two APIs, one for the customers (that will get outdated with lot of missing features and be less battle-tested) and one “real API”.

[paulddraper]

Releasing a public API is.....an enormous commitment. Anything you do has to be maintained for years.

[hakunin]

Redesign: I've responded to the redesign argument in another comment. It's easy to find if you search the page for "rare event".

Mobile app: this is addressed in the article.

Naming: Usually most naming for different parts of pages is handled by the design(er), but even if not, once you have an approximate naming convention for parts of the site, naming becomes easy. And the stakes for these names aren't that high, because you are only scoping everything down to a single page, so global consistency and precision in naming is not that imporant. It just needs to be enough for someone to understand what it most likely refers to on this page.