You have described a strategy to avoid having to deal with bad maintainability, not a strategy to avoid creating bad maintainability.
1. I see "unmaintainable" as mostly a factor of time (or age of the codebase), of changing requirements and people working on the code. So giving advice on how to write the code to be maintainable isn't gonna help much. If people turnover quickly, they won't bother, if they turnover slower, they will do their best to keep it maintainable and yet fail.
2. People who follow (intentionally or not) the advice I gave only ever see maintainable code, so from their perspective, it leads to (having to deal with) maintainable code.
3. (= 1. + 2.) Sadly, the people who are the most displeased with the legacy code not being maintainable are the ones who tend to leave quickly (or write something on their own), paradoxically, compounding to the problem of the unmaintainable code in the first place!
I don't think there is a good solution to the problem. Maintaining old code is hard work.
(Written by someone who has been doing brownfield projects, often bordering on code archeology, at the same employer for far too many years)
Could it be that a good definition of maintainable is simply "easy to understand by others"? Then, of course, code earlier in the life cycle tends to be easier to understand.
Then there could be a difference between "easy to work with" (by the original author(s)) and "easy to understand by others". But assuming original authors were good programmers, I am not sure how they could cause this difference to occur.