In general I'm in total agreement with your points, but in practice this one is really hard to do well. The majority of code that did anything useful tends to stay around for a long time, whether intentionally or not."There is nothing more permanent than a temporary fix."
This is why best practices and established patterns are so important for long term productivity. They help bridge the gap between effort and quality and in general work well. They're not panacea, but the exceptional case is a different issue.
Regardless, my hope was to offer some rebuttals for bad code critics. Getting defensive at every criticism is not productive. Giving in and trying to fix everything is not a smart way to handle criticisms either since you might just be wasting time and money.
Critic: Component X could be Y times faster if you did it this way.
What you should ask yourself: Is performance of X actually a problem that your user base cares about or has complained about? If you improved performance of X, would it help your team in the long run?
Critic: Your code for X is hard to read.
What you need to ask yourself: Is this a core component that is going to stick around forever or is it some temporary thing you slapped together that is going to be replaced in the near future? If it is going to stick around, you should definitely refactor to make it readable. Otherwise, not worth the time unless you literally have no other priorities.
Critic: I noticed this new UI component you wrote has a bug.
What you should ask yourself: Is it critical to your company/team's image to have your UI working perfectly or do your users mostly care about other functionality which is higher priority? Does the bug stop anyone from using your software properly or being able to do something they want to do?