The point being to reiterate yours -- there's a decent chance the code you write will survive in some form far longer than initially told or intended.
The actual epoch chosen was the time of the first moon landing, a little prior to 1-Jan-1970 (I like this touch, something with actual historical significance and likely documentable to a fraction of a second, rather than an arbitrary date).
Nowadays I'd say it's 50/50 whether a new project there will last a while. More than half the work is pet projects that won't ever be used for real, if at all. While the other small half can live for many years. It's possible to get a pretty good idea of where it's heading from the start, with experience.
Early adopters of computers were doing so in the '60s and '70s. By 1985 mainframes were widespread and PCs were becoming common. Check out 
1983: C++, ARPANET
1984: Common Lisp
35 years ago was also the time when 8-bit personal computers were becoming popular (well, not as 'popular' as 10 years later, of course) in homes, and hobbyists and kids could start dabbling in programming.
Everyone will have perfectly good intentions, from PMs to directors to ICs, but "this is only temporary" almost never is.
But I have found that every code base needs some kind of way to write "temporary" code AKA code that needs to be refactored at least.
If you don't define a place (and time) for this then it will happen anyway. Just all over your code base: patches, fixes, workarounds, todos.
The clearer it is to distinguish temporary code the better: "Start just writing what works here and then gradually move pieces of it over there, while testing and refactoring it."
When your code and communication is setup like this, then you will naturally incorporate this process because it is both pragmatic and very visible to everyone.
It won't happen, and it has never happened unless those sections end up failing catastrophically.
We don't have enough money to do it right once, but we have enough money to it wrong twice - Me, 3 years ago.
If I write something that is just to keep something running 'for a couple of days' and then ends up being part of a backbone for a company (because it ain't broken, so why replace it?) is something I could not expect but there are at least 50+ 'blobs of software' out there by me where exactly that happened over the decades.
The way you deal with "temp code" is to slightly improve the aspect you are changing, each time you change it. Maybe you did something weirdly hacky with magic numbers everywhere - when you need to add another magic number you refactor that aspect to no longer use them. Or maybe if they're starting to look more like types you do a refactor to enums or classes.
Then the places that can be shitty remain shitty. The places that can't are fixed up over time.
The real take away here is that real (objective) mess hurry-hackjob code bases are good enough to last many years so you probably did the right thing.
Legacy system cycle* Was the code written in a system that is expected to have a long cycle? (20 years+)
Attribution* Can it be easily attributed to the owner?
Access* Do you have access to enough source codes to confirm it to be true?
Quality* Does the code have an appropriate level of quality?
Company* Did the company survive the peaks and through of capitalism even if it means being bought out?
Give a look at Scott Adams's goals vs systems. Personally, when I stick to my system I am less likely to look to something else to judge if I'm "doing enough" and as a result, imposter syndrome doesn't have a chance to creep in.
Anyone know the best pay to stress ratio industry for this? Finance/Gov?
and I really wonder what happen in non coder's brains..
> And it's terrifying. Suddenly, you feel like a Jon Snow who knows nothing, and self-doubt starts to creep in.
I was very fortunate in my first position to not have any imposter syndrome, and I think it is partly because I did not ace the interview. I was honest when I didn't know an answer and showed I was willing to learn.
Of course, the value of maintenance varies depends on the stage you're in. If you don't fully understand whether this is a market or not, then it's better to write quick sloppy code. If you understand the market and customers, then maintenance will reap rewards. How to convince your team to switch from one mode to the other?
Sure, they all sound plausible and we may have even been told these things by mentors during an internship. But is that going to stop an early 20-something from charging into into a project shit-storm? I think not.
Some things are best learned by trial and error, how else can you know the true pain these "commandments" help you to avoid?