Also cars are driven more than repaired. Highways are used more than they need to be maintained. Yet if you don't include some thought to how to deal with a sit

Also cars are driven more than repaired. Highways are used more than they need to be maintained. Yet if you don't include some thought to how to deal with a situation where something breaks, this could (and very likely: will) eventually come back to haunt you. But code is not the same as your car. If money is not an issue and your car breaks you could just get another one that drives equally well. Try doing that if your code breaks. So whether values like readability, maintainability etc. can be important for good code is out of the question — what remains an open question is (on a per file basis) how to priorize between those two if such a need arises. And that isn't a small "if": One should guard themselves against the simple thought that these are inevitable tradeoffs that are mutually exclusive. You can easily make code that is both unreadable and doesn't run well. You can also make extremely readable code that runs nearly perfectly. The latter is of course harder than writing the same code to just run well, but if you are not coding alone or your project is beyond a certain scale it might be well worth the extra thought. The solution space for "clear structure" and "good performance" is smaller than for either of those alone, so finding a good solution here is a bigger challenge, but depending on what you plan to do it could be worth a try.