Also, having consistent formatting makes it very easy to read through large amounts of code. If you know how the code is laid out, you don’t need to focus on everything and can “squint” through it to get a good idea of what’s going on.
Agreed with you and the GP. In one project I’m on, I pushed for linting and formatting checks in our CI not because I’m an “insane weirdo” who cares too much about formatting, but precisely because I don’t care, I just want it to be consistent. I don’t really have an opinion about which style or format or whatever is better, I just don’t want to have to read through 6 different coding styles when I scan through my colleagues’ code.
Having a consistent style enforced by an automatic tool set (linter/autoformatter/etc) means no time needs to be wasted in any given PR arguing about style, or waiting for someone to fix a style mistake. You might still waste time arguing about what the rules should be, but that's often less than the cumulative waste of fixing avoidable crap.
I believe though that you should just have some system in place to automatically check/fix these issues(for the most part). I've been in far too many environments though where PR reviews are just surface-level formatting nits and don't address functionality or architecture at all..
The solution to this is to use an automated formatting tool for the entire team and have it automatically run prior to review and be done with it.
This is done in many teams. Go has made it really easy via its gofmt tool. The trouble is that it's hard to do on a large existing codebase that's not consistently formatted: doing a mass format messes with the line-by-line commit history, and on occasion introduces bugs.