I think I couple of those points come down to the tech-lead to write a "Definition of Done"

1 - This is useful for junior members or new members to know what to expect. For example, "Definition of Done" would include that a new function should be documented, it should be refactored into clean code by the code standards, it should be tested by QA, there should be unittests covering the function, the function should be released to production to be marked as done - etc

2 - When giving managers that don't know anything about coding an estimation - either by you, or by someone in your team - they can take the Definition of Done" as a reference point. If a manager asks how long something will take, you don't just consider "Oh, I guess I can build this in a couple of days". Yea ok sure, you can build it to meet the managers minimal requirements for the function to kinda work but its messy code and untested - so if you keep in mind that there are loads of other meta-things to do besides just building code, you can pretty much double your initial estimation

Otherwise you just accumulate more and more technical dept, and at some point your "just build it" estimation gets inflated because for every change you have to touch lots of 1000 line files, figure out what broke by the changes, fix that, see what failed now, etc etc

And it would have been better in the long run if you would have spend more time on it while you were working on the function