Why not think about the program you are working on as a program that is built to support the open standards that enable people to communicate and concentrate on performance within these standards?
If someone wrote a bad performing non standard compliant code the program should throw an error.
Making bad code run faster is overstepping the boundaries.
But we're not making "bad code" run faster. We're making code run faster. The original counterpoint was that we shouldn't be, because improving the performance just gives leeway for bad programmers to use it as a crutch.
We don't prioritize bad code for optimization. See usage of 'with' in Javascript. We don't actively try to make it worse, but whenever a decision is presented which regresses 'with' performance for gains somewhere else, it'll probably be taken because we don't care about 'with' running fast.
But the example I mentioned: histograms of max GC pause times on a particular website. Or particularly bad janks, or long amounts of time spent in JS which might be the result of poor JS execution..
None of these optimize "bad code". They're just standard platform performance optimizations that help all programs. That will include "bad" programs as well.
Making bad code run faster is overstepping the boundaries.