Who you are writing for

Code is read far more often than it is written, and the person reading it is usually you, several months later, with no memory of what you were thinking.

That is the whole argument. Not elegance, not style preference, not a rule from a book. The question for every decision is whether somebody arriving at this file cold can understand it quickly.

What unreadable code actually costs. Every change takes longer and carries more risk. Bugs hide in code nobody fully understands. New people take months to become useful. And eventually the code reaches the state where nobody will change it, only add beside it, which is how a codebase becomes something people work around rather than with.

Clean does not mean clever. The most common mistake by capable developers is compressing something into a dense expression that demonstrates skill and takes ten minutes to read. Three plain lines that anybody understands is better code, and the fact that it looks unremarkable is the point.

It also does not mean over engineered. Layers of abstraction added for flexibility nobody asked for make code harder to follow, not easier. Simple until there is a reason.

The test. Read your own code from a week ago without the context. Anywhere you have to work out what is happening is where the next person will lose an hour, and you now know exactly which parts to fix.