The primary purpose of code review is to find code that will be hard to maintain

I think that this would be better directed at the person who posted "no one ever finds bugs during code review" rather than at the person who said that just re-reading code is (obviously) not an effective way of debugging, and is better thought of as a time to make code clear enough that bugs will be more apparent or less likely to be introduced by later authors.

> I’m not a fan of these blanket declarations that code review isn’t about reviewing code.

Using a shovel to dig a hole isn't about using a shovel, it's about digging a hole. Reviewing code is a necessary prerequisite to finding code that will be hard to maintain (and finding any number of other things, and knowledge transfer, and getting acquainted with coworkers' coding styles and domains, etc.) It is not a purpose in itself, but a tool.

> code review isn’t about one thing.

But you just said that code review is about reviewing code, and explicitly not about "some other thing" in the beginning of the sentence, right before listing two other things that code review could be about, and then insisting that it could be about many other things. The author is saying that it is primarily about one thing, likely because in their opinion it is most effective at that one thing, and that one thing goes a long way into solving other issues.

It isn't like they said "ignore bugs during code review, never learn anything from it."

I agree with the OP. Code reviews are finishing steps where things are polished, and polished code should be correct code, but more importantly intelligible code. If your code is clear, the mistakes will be obvious to more people than if your code is not readable. To make it simple: you've written something and it feels done, now you want someone to read it to see if it makes sense to them. No different than any other type of writing.

> making code more readable is a "change." I don't know what you're trying to say here.

Yes and this is exactly what I am trying to say. The author limited what is the purpose of a code review like it's has really this limitation but, in practice, the code review is widely about what you think it should changed on the code by multiple reasons: readability, manutenibility, performance, security, bugs, use cases, test coverage etc.

Making code more readable is just one of the reasons why you want the code to be changed on a pull request, it's not the primary purpose.

What's the worth of this comment if you've decided to keep this purpose a secret?

The second sentence is just nonsense. There are no automated maintainability devices (quite yet.) You seem to be literally declaring that linting is the only worry that any software project would have when it comes to maintainability. Everybody is linting, the conversation begins after that.