The reality is that as long as your style is consistent, very few people actually care what that style is.
I can imagine smaller teams/single individuals being very picky about how their code looks and there is nothing wrong with that. Once you have larger teams that becomes a waste of time since you'll likely have much larger problems to solve.
> as long as your style is consistent, very few people actually care what that style is.
This is an oft-repeated myth. There are some style rules for which that is true, but for some, there are objective, logical reasons to prefer one style over the other.
For example, mandating the optional comma after the last time in a list whose items has been split over multiple times results in more readable and logical patches: if you mandate the comma, a patch that only adds items will only have added lines, whereas if you don't, a patch adding items can have a mix of add/remove lines.
Pushing operators to the subsequent line makes it fundamentally easier to read as they all align, vs. a ragged right edge, and this is doubly important if the operators aren't the same, as it makes that far more visible. (Though this is harder in some languages with odd behavior around this, such as JavaScript.) (This also affects patch readability in many languages, and in fact, I'd say patch readability is the driver of many objective reasons behind styling choices.)
And so forth. I'd wager as many rules have logical reasons backing them as those that actually do boil down to literally just stylistic decisions.
I can imagine smaller teams/single individuals being very picky about how their code looks and there is nothing wrong with that. Once you have larger teams that becomes a waste of time since you'll likely have much larger problems to solve.