Writing readable code is not "nitpicking". It is common that an author doesn't see why their parameter name or function name is misleading but their reviewer, who comes to the change without as many preconceptions, sees it right away.
I disagree that the reviewer comes "without as many preconceptions" - they just come with different preconceptions, the ones they're used to. Programming language is a language like any other, and each person has their own style of writing it, and they'd prefer the rest of the world to use their own style because it's "more readable".
But I think that most people consider their personal preferences to be better and more readable just because they're used to them, so I tend to take the opposite attitude as the starting point. There were more than a few situations where I've had a coworker tell me "just read the code, it's very readable", only to spend the next two weeks just trying to figure out how it works. Sure, once you figure out how it works and it "clicks", it's no longer (that) unreadable, but the fact that I have to spend so much time reading the codebase in the first place made me convinced that personal familiarity is a great part of what "readable" means.
Entire group of people has to think otherwise due to proliferation of that style.
Things like "lots of small functions vs. few large functions", or "exceptions vs. sum type return value", are such cases - they seem subjective, but they're less about preferences, and more about the kind of work a given reader is doing. Either choice is better than the other for some kind of work. We can't improve on this until we move past working directly on plaintext, single-source-of-truth codebases.
Plaintext is fine. Single source of truth is obviously needed. The problem is with insistence on only ever working directly on it, which leads to a futile attempt at inventing styles and languages that would express every cross-cutting concern and needs of every job in a clear and readable fashion. It's just not possible.
(And yes, I believe the bleeding edge of programming language development is effectively just spinning the wheels now - adding increasingly complex abstract math to programming languages isn't going to help square the circle.)
To put it this way, you should use Kotlin vals with get methods with getters rather than fun getXXX() functions, but this is controversial, so I always suggest it as a nit (Nit: maybe use val xxx get() = ... rather than fun getXXX() = ...).