Sub-question:
* If you are selective in your style enforcement, how do you do so objectively without angering others?
Anymore the easiest way is just setup the standard IDE profile for the language and make sure everyone uses it. This removes 80% of the work and makes it easy for most people. I also like this because I personally have some ways I like code that are contrary to what a lot of people like, so when I setup the IDE it makes it easy for me to stick with the standard versus what I might want to do since it is more work to change it. I found this to be true for most engineers as well.
Overall, I don't like the idea of huge coding standards however, unless the project is a vital system. For example, with embedded devices I like a more strict coding standard because the cost of errors are much higher, but for web I find more lax coding standards acceptable because the risk is usually lower in terms of cost and time. However, the web argument changes when you say there are millions of users of the software, then standards become crucial to quality and reliability.
In the end it comes down to cost to maintain the software and fix defects, standards lower that cost so they are the right thing to do.
Personally for my Javascript projects I've been using prettier with their combined linting rules. I don't like every choice it makes, but it keeps the code clean and consistent.
I also like to make sure the team is down on all the rules you can't auto-format and I like to keep those light. Use es6, no lodash, use native promises, don't use arrow functions to define class methods... that kind of stuff, all very personal and project specific.
This is why Go,Rust,Swift, etc have built-in language specific formatters. C/C++ have cppcheck or clang-format to format to a defined style. Something like 'clang-format -style=llvm main.cpp'. With clang-format, it is possible to define your own coding style with this too.
Another use-case is when you have your own open-source library and you want external contributors to send patches. If it isn't written in a idiomatic style, then it would be seen as immature to use and so hard to read, only the creator can read it.
Enforcing a code style also helps with code reviews for clean patches. But this use-case happens with open-source projects but still applies to closed-source ones.