My take on it is a bit tangential - it's not about readability, it's about maintainability.
Reading is just looking at the code and thinking you can read it. It is usually assumed that, to be readable, it has to be readable to someone who has put no effort into understanding it.
Maintaining is making changes to fix bugs or implement new / changed requirements. Reading is just part of that process. I don't know of any maintainable code that doesn't require a learning curve on the part of the maintainer, and to someone who has not climbed that curve the code looks "not readable".
At the same time, I think it is part of a programmer's responsibility to teach the maintainer to help them climb the learning curve. One way to do that is to leave step-by-step instruction on how to perform the kinds of future changes that could be anticipated.
I often see code that is puffed up with whitespace so less of it fits on the screen, and given verbose naming and gabby comments. This gives the impression of readability.
