See, the flip-side is:
I don't care how good your algorithm is if it's written in an obtuse, unmaintainable manner.
There are plenty of coders (especially those new to the profession) who don't understand the value of tidy code. The smart ones quickly understand and tend to ask for some tips. That's the first (and for me, primary) reason for having a Coding Standards document.
The second reason is to reduce friction when viewing each others' code. Local vars should be 'someVariable'. Instance vars should be '_anotherVariable'. Methods should be 'SomeFunction'. I physically twitch when I see underscores in variable names.
But, a Coding Standards document should be clear on 'must-do' vs recommendations. We state that you should split multiple-clause IF statements tidily to avoid excessive horizontal scrolling. But we only provide recommendations on how to do brace placement.
Every single point in a Coding Standards document should have a defensible reason to be there.
Our CS doc is in a Wiki which lets us have a comment section for each page (and there aren't many pages overall). If anyone wants to ask why something's in there, or suggest an alternative, they're free to. The doc's existed for 9 years and is largely unchanged other than to add explanations and extra languages. We most recently added some docs on SQL stored procedure styling, since ours were abysmal - copying and pasting SQL from Management Studio's view designer is a 'go back and do it again whilst we laugh at you' offence now :)