Bikeshedding is prevalent in every popular area of human study, because it's easy to talk and write about. It's not representative of what matters to those who get the job done.
Attitude is, if I can argue with someone and have it in a fun productive way - even if we don’t tackle most important thing we should work on at the moment - it still might be valuable.
If I have to deal with smartass that nitpicks on variable names, he wastes my energy and any will to do further work for the day or if it is more heated and goes over some “Astro architecture” might even burn my willpower to do any work till the end of the week.
I don't mean to bikeshed, but you seem to be describing bikeshedding. Bikeshedding in practice is often accompanied with aggressive arguments because some (or both) sides just really want to be right about something, as a way to offset their real worry, despite neither choice solves their real problem. Although I guess it could also be a pleasant chat, why not.
Consider for example the bikeshedding society did on whether to distance 1.5m or 2m during COVID, and how precisely and how long to wash their hands. We had a ton of those. When people feel out of control they want to own a decision that makes them feel like they're back in control.
Programming is complex at scale. But bikeshedding about how many characters our lines, how many lines our functions, and how to name things is always there for us to argue about.
Oh and whether a class is truly single responsibility, that's an evergreen.
That's not bikeshedding. Bikeshedding is focusing on an unimportant but familiar aspect of a complex project specifically because one lacks the technical knowledge to discuss the important parts. Bikeshedding might involve nitpicking, but it doesn't have to, and one can nitpick without bikeshedding. Maybe a code reviewer is genuinely so inept they can't understand anything more complex than naming standards, but far more likely they're just a bit neurotic with regards to following standards.
The definition of bikeshedding is nitpicking unimportant details because the important details are difficult to figure out, discuss, or acknowledge. It doesn't specifically point out "ignorance" as the sole reason why bikeshedding occurs:
"The term was coined as a metaphor to illuminate Parkinson's Law of Triviality. Parkinson observed that a committee whose job is to approve plans for a nuclear power plant may spend the majority of its time on relatively unimportant but easy-to-grasp issues, such as what materials to use for the staff bikeshed, while neglecting the design of the power plant itself, which is far more important but also far more difficult to criticize constructively."
A form of "one-man-bikeshedding" is when you keep postponing important work, by constantly checking email, cleaning the house, or doing other unimportant busywork. You are not ignorant about what is important. But you procrastinate as it's much more difficult and painful to face it.
The same dynamic is present also in groups, where groups naturally tend towards endlessly debating nonsense, as it's easy-to-do busywork.
Weird that you put ignorance in quotes when I didn't use the word.
Again the point that I'm trying to make is that someone making a big deal out of standards is generally not a result of other things being "difficult to figure out, discuss, or acknowledge" but instead because some people genuinely care a good bit about sticking to standards.
