A good quote to start this rant is one that I just read a couple of days ago:
“Programs must be written for people to read, and only incidentally for machines to execute.” - Abelson and Sussman
I see guidelines as a Strunk and White for code. If you pick any book, you will notice it has a flow. Each paragraph starts with a tab, each sentence ends with a punctuation sign, there is no space between parentheses and their content, etc. What coding guidelines are suggesting is the same thing. If you have been online since the early 2000 you have probably noticed the l33t (IRC) speak. You can read l33t speak, but is easier to use proper words and formatting.
When you are working on project (more then 100 lines), you are making a plan, draw an architecture. The coding guidelines are one of the small, overlooked details of that project. Most of the times, they are your particular ones, implicit ones, even if you did not declare them as such. Did you use two different styles in projects using the same programming language? I guess not. We exclude the projects that were written years apart, as styles may evolve. When you are part of a community, it is nice to follow their rules (implied or written). In that community some have their quirks (eg not using coffee script), why adding another one?
Coding guidelines do not cover your ass. If you need this, then add a couple of processes. Start with code reviews (which are a good idea), add QA sign-off and then formal sign-off. Coding guidelines are good to easy in project switching and project collaboration. I was reading somewhere that Google enforces the same C++/Python/etc coding standard.
I will not go as far, but I would like to use the community coding guideline. I have seen colleagues sending code back, after code review, because of wrong curly braces placement. I believe that is a bit too much.
I agree that some people are too attached to rules and processes (after they become a manager) but that is like the bicycle shed problem, everyone knows how to paint it. I am arguing for easy collaboration, and if possible easy automation of finding your own mistakes (JSLint or FxCop in C#).
Guidelines are not about not trusting your team. Trust is earned by shipping great software, making your customer happy, or helping your colleagues (when in distress), not by using proper format, commas et all. Guidelines are not a process or a method. I doubt that there are consultants that your manager can hire to sell them to you (cough agile).
In the end, I believe that following coding guidelines (but not enforcing them) will help the person that uses them because the code will be easier to read three months later and peers will find that code easier to understand.