It is what it is, everyone gets the same, shut up and work on what matters.
I'm surprised you consider it a lot of energy spent, I tend not to spend any on this, it just runs automatically on my code and I drop out of pretty much every discussions about linting as it's good enough with automated tools.
I also used to work in places where there was no such tools, and there I had to actually spend time discussing and thinking about linting.
Edit: one could also use single or double quotes in strings, and it didn't anger the grammar nazi bots as there were none.
That's why I like Go, every piece of code looks the same, there's one default enforced linter and this discussion (or discussion if discussion should be allowed or prohibited) doesn't even cross anyones mind.
However since you've asked so nicely here you go: everybody’s code looking different is because all humans are different. It's what makes us human. I am very serious about my craftsmanship, and I bring my "humanity" to it: sometimes I include a cultural reference (as in the example above), or an internal joke in the name of a (very long) variable, or vent my frustration in a comment.
My first ten years of writing Python were uneventful; nobody commented about my style and I never commented about others'. With the advent of grammar nazi bots, everyone is supposed to now please them by writing completely bland code, which in my opinion degrades me from a craftsman to a code-monkey. This is dehumanising, in a certain sense.
I care how the food tastes, not that the chef has a really cool Japanese knife and is really fast at cutting onions.
Now imagine a chef who has a nice little restaurant but is now being sent a couple of "quality assurance" guys from McDonald's who tell him that his choice of potato variety for chips does not exactly conform to the "standards" defined at the mothership.
If sieving the spam from ham in code reviews is your thing, go have fun.
I personally prefer code that is automatically and unconditionally kept in the exact same shape, preserving only the intended changes to stop the team from wasting time on formatting or reviewing.
Compare that with other languages where you need to load a different set of prettier rules, code formatting tools and follow contribution guidelines on how things should look like depending on the opinion of the maintainers.
Which might be more overrated OCD than anything worth it. If you like that, you can add a formatter at the end of the chain or even just when reviewing.
I have never seen this not happen, barring using autoformatters. I think Go and Rust have had great success avoiding all these dumb arguments by having built-in opinionated formatters from nearly the beginning.
I remember people saying this exact same thing about Python ~20 years ago.
You probably haven't written diverse enough code.
Afterwards it will affect production code everywhere on the planet. :)
And yet, as per the example, the bot force worse linting decisions, and even pushes towards more bugs (e.g. future readers missing the comment intention since it now applies to all 3).
Pretend they don’t exist as much as you’d like, tell everyone their lived experience is wrong, that the tools arose from delusion and not any real world need, and that they benefit no one.
I’ll keep using them though, and never suffer from someone writing typescript with 4 spaces, leading commas, and no semicolons again.
(I think that in their case it was partially because uniformity made correcting faster.)
Worse, sometimes you would start working on a project without having that discussion first, only to discover a few days later that the code was failing because different people had different indentation settings in their IDEs, both regarding tabs versus spaces and the number of spaces. You would then have to pause the work, go back, have the discussion, and decide who was going to fix all the code committed so far.
This only stopped when linters became popular. They may be a little like vaccines: when they work, you do not see them working, so it is easy to forget what things were like before. But believe me, when they appeared, they were a breath of fresh air. We could finally focus on discussing the work rather than the conventions.
And tabs versus spaces is only one example. There used to be PR discussions about countless style issues throughout the entire lifetime of a project. That was not entirely unreasonable, because a consistent style genuinely makes a project easier to work on. But when every individual convention has to be negotiated by humans, it takes enormous amounts of energy and becomes tedious very quickly.
I can believe the latter, and I can assure you this was a Big Deal back in the day. There's a reason Go ships with gofmt, and gofmt was somewhat revolutionary for being a built-in "you gotta do it like this" back in the day.
Tokens are burnt, that's the most important part. And with more of the generated shitty code there will be more tokens spent in the future.