I agree that enforcing coding standards inside a company usually has some drawbacks. However, I think that a certain level of cleanliness and use of good practices is mandatory. I don’t care that much about putting the curly braces in the same line or the next but I do care about naming methods and variables coherently and making sure your code is readable and understandable by others.
Of course some proof-of-concept projects and prototypes can be almost butchered just to make it in time for the presentation but when you find yourself patching a project started this way you will agree with me on this: that idea should be refactored into something clean and easily maintainable. Of course you shouldn’t do it if you’re going to dispose of it but we’ve all had projects that started with some quick n’ dirty code and evolved into key projects in our company’s portfolio. In my opinion, the key is to be flexible, known when to allow some room for breathing and creativity and when to demand a minimum of clarity and care for the code.
You wouldn’t want junior developers spending most of their time thinking about how pretty their code looks or how are they going to be bashed in a peer review. We have tools that take care of the basic details like tabs/spaces, indentation, auto-formatting and auto-completing, refactoring methods and variables, we can focus on the task instead of the coding standard. There are plenty of excellent IDEs out there that will happily take care of those things for you. Just sit back, think, and start coding. The rest will come to you.