>>70 8/10, you've done well to make me use up 60 minutes of my time.
The tactic of don't-optimize-early is a tactic in the strategy of managing developer productivity. This plays into the principle of coder's time being expensive and limited, coder's experience and understanding being limited, and computing resources being cheaper than coder time.
By understanding the problem domain foremost, coders can use that understanding to guide their craft. By establishing some working but naive code the coder establishes a standard that can be improved and also contributes to understanding the problem domain. By analyzing the established situation, the developers can form targets to apply the optimization techniques. By having concrete and achievable targets, the coder can focus the effort into completing each target as they come as opposed to indescriminately applying optimization techniques to potential (unwritten) code.
If everything was written like that from the beginning, the thing would be FUCKING INSTANTANEOUS.
Coders aren't born with an understanding of their problem domain in coding. This understanding is learned through experience.
Like it should be, because two decades ago people were solving the same problem in 10MHz CPUs and it ran at good speeds.
I think your understanding of this matter is shallow. Two decades ago, we couldn't do many things interactively that we can do today because of limited computing resources.
You have massive and bloated monstrosities today partly because of a lack of understanding of the systems used as well as the lack of understanding system understanding of the problem domain. Another problem is because of strong demand to ship working programs within the schedule. This often means that programmers use tools that are intended for quick results and the developers having less time to analyze the problem domain. Part of the problem is also the mentality of profitting through artificial scarcity and subjugating users out of freedom 1 of free software; the proprietary software masters take it upon themselves to be the gatekeepers of the software that was developed in their name; the gatekeepers choose to keep the burden of indescriminately hacking at code monstrosities because of misguided notions of "Intellectual Property".