Good code is rarely read

You can have an stinky old piece of legacy software that no one ever reads because that system is deprecated and slowly getting phased out, and we can live with it in the meanwhile.

You can have the most elegant a beautiful piece of code that gets read a lot, because it is in the critical path of a very active and rapidly evolving system, and people need to reference, modify and extend it a lot.

However there is a crucial way where OP is wrong: there is a pull and push between code quality and how often it is read. If your code is a legacy big ball of mud, people will be less inclined to touch it, probably going to the extend of rewriting the whole thing. On the other hand when code is well written, people are less afraid of digging into it.

Lastly, even if OP thesis was correct, I don't know think it would change anything. Strive to write the best code you can within reasonable constraints, independently of how much other will read it (which in my experience is almost always underestimated).

The best code and code bases allow you to quickly understand how they are structured and don't necessarily hold subtle, nasty surprises - or at least make it obvious if something is a nasty, subtle surprise. Those code bases tend to be a quick read.

The bad functions and code bases require you to carefully consider every little aspect of every single line in detail. And I don't just mean "read every line", I mean "Dissect lines based upon language specs, and also keep in mind this is interacting with 5 different other parts of the code base. Or not. Who knows?" In such code bases, just figuring out what something does tends to be a slog.

This is a poor world view and is what leads to unwieldy systems with weird interactions that are buggy in just the right situation.

I understand what the author was trying to express, but the sentiment is poorly expressed. They conflate "used"/"run" with "read" several times. IME, good code is readable code, but not all readable code is good code. Clever code is normally much less readable. At the end of the day, the lifecycle of any code you produce is such that it will generally be maintained far beyond the time is was written. To me that means you need to write code with maintainability in mind. If you cannot read and understand the code, how can you expect the effectively maintain the code?

Simply having a clearly defined function name, arguments, and documentation doesn't mean you can ignore making the innards maintainable.

Finally, as others have pointed out, you want your colleagues reading good code so they can learn to write better code. No matter your level, you should never stop learning to be a better developer.