I agree that some form of standards are good, btu I really disagree when I see some of the trivialities that usually end up in most standards.
Generally, coders will work to an established style anyway - they will try to make their code look like the code that's already there, so writing down a heap of 'you will do x' rules is just annoying and pointless. If anyone doesn't come up with code that follows the team's implicit guidelines, then you can be certain that person is not a fully-signed-up team player and you can have words with them.
The standards that I do think are important are to do with structure and organisation of code - not to say how many lines of whitespace need to be between each method, but how it'll be laid out in your SCM; what kindof folder structure to aim for; where to put the binaries and the release notes.
If you've ever seen several open source projects, even those that have their own standards, you'll be able to view all their different code and understand it. How many OSS projects have a dependant project that follows a different coding style? how many coders worth their salt can read both code styles and understand the codee, even though they don't use the same standard!?
I find it sometimes takes a lot more effort to find out where the binaries get built or how to find the readme that tells you how to set up the dependancies. So at my place, we focus much more on standardising these things so anyone can grab a project and will immediately know where to find a readme that will tell you what kind of project it is they're looking at or where to find the binary to install. It also has the benefit of forming some partof the documentation and geting rid of the 'grammar nazis' that love those officious old coding standards!