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.

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.

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.