The main part is to avoid holding state in two places (frontend and backend) if you can do with holding state in only one (either frontend or backend).

Unless you're building an app that holds data locally, for most web apps, you should be pushing state down into the backend. Fat models should be your single source of truth, skinny controllers, and service functions in order to separate data from code for testability.

Avoid caching as much as possible until you absolutely need to. As soon as you introduce caching you now have multiple sources of truth instead of one.

or be stateless… ;)

after you re-write it (either immediately or with time) you will end up with the same thing, just a different kind of soup. using vanilla-whatever you will eventually notice you are doing “X” over and over again and then you’ll start writing small libraries (or even worse, some internal “framework”) which over time will get stale or will get bunch of features from devs that need “just that plus a few more things..” ad infinitum…

This is simply not true, and has never been true anywhere I've worked. We can do everything with a much better UX in about 2,000 to 3,000 lines of code, instead of ~25,000 (and almost 2,000 dependencies).

It's a boring tedious "true-ism" that keeps getting pounded. I don't really know what else to say, but it's simply just not true.

What is the longest you have ever worked on a single piece of software? If you are in some sort of consultancy or jump jobs every 2-3 years it most definitely won't be true. You stay with a product for 5+ years it is bound to happen unless your dev shop is like 10 people. If you think this is not true AND have spent 5+ years with the same piece of software you are an outlier...