In my experience, that clause is not required. Code that's been designed for easy testing is better code, period. Not just because it's been tested. Code designed for testing tends to have cleaner interfaces and is better modularized.

Unit testing can easily lead to arbitrary modularity or code fracturing, which makes code harder to use and reason about. Good code should be designed for solving problems, easy use and readability. If your code is designed primarily for passing code coverage checks, then it probably is not very good.

It does require a degree of latitude and good judgement. This only comes from experience.

... which is just re-using your code in a slightly different context.

This is generally my goal with making code testable. If I can make it modular and re-usable, that makes it much easier for me to maintain and extend in the future.

"Does this thing roughly do what I think it does?" is a secondary goal for me.

One way to look at it is that optimising for testing is optimising for correctness

Not always. The GP post is more insightful than it might appear. A lot of reasoning used for arguing in favor of adding more unit tests is circular. "Good code is unit testable, so unit testable code is good."

Very often, optimizing certain kinds of code for unit testing makes it significantly more complicated, with none of that complexity helping you in the actual program. This is especially true for "end user" code, such as controllers.

I agree with what you said about "end user" code actually. I guess I am really arguing in favour of testing, not specifically unit-testing.