In a couple of $WORKPLACES, people have been discussing introducing coding standards, and enforcing them. Each time, I've been successful in changing their minds.

Now, I'm all in favour of writing good code. But once people are talking about coding standards, they almost all first focus on layout nits. Like whether you may omit parens when calling a function. Whether you should put spaces before a bracket/curly/paren, after it, or none at all. Whether you should write $$aref[1][2], $aref->[1][2] or $aref->[1]->[2]. Where to put opening and closing braces of a block. Whether you should use "foo" or 'foo' for a string that doesn't use interpolation. Do you shift from @_ or not? Or other visual things, like whether every module should start with 'use strict'.

They seldomly focus on the real issues - or if they do, they aren't willing to put it up front in the coding standard because it's so hard to enforce. 'use strict' isn't important. Using properly scoped lexical variables is. And if $WORK prouds itself it's only hiring "top" programmers, it shouldn't matter programmer A always uses parens when calling a function, and B only when needed.

As for the particular points:

Improved code maintainability.

Perhaps, but that strongly depends on the standard. It also doesn't mean code that doesn't adhere to some standard isn't maintainable. But what's more important is the trade-off. Unless the standard is your own standard so you don't have to think about it, following the standard takes an effort. I'd code much more slowly if I had to follow everything PBP says - just because it sometimes wildly differs from my style. So the business pays a price: it takes longer to write new code. Now, if your code lives for many years, and needs regular maintainance, ease of maintainance is important. But if code has a short half-life cycle, faster delivery of code at the expense of creating "techical debt" is better for the business.

Improved code quality. In particular: testability, supportability, portability, security, efficiency, robustness.

That requires a very good coding standard. I'd be interested to see a Perl coding standard that improves code in half of the mentioned topics.

Improved development speed. Your developers don't need to make all decisions starting from first principles.

That I strongly disagrees with. Almost any rule a programmer has to follow decreases coding time, it doesn't increase it. (If it did, it wouldn't have to be in the standard.) I don't understand your argument though. What have first principles to do with coding, or coding standards?

Better teamwork. Don't waste time with needless debates. Spend your creative energy on things that matter.

I've wasted time on many (needless) debates about coding standards, including the time I spend writing this message. I've never had a co-working coming up to me asking why I put (or didn't put) a space somewhere, or why I omitted an arrow. Nor do I ask my co-workers about details. Now, I might ask a co-worker why they used a cubic algorithm instead of a quadratic, or why they opted for Module X instead of Module Y, but I doubt such things could be covered by a coding standard.

Better performance under pressure. Under stress, people fall back on what they've been trained to do.

But what people have been trained to do is most likely not the rules laid down in standard of their current $EMPLOYER. If I have a dead line loming, I'm much more likely to finish before the deadline if I don't have to check my code with the rules in the coding standard - its rules won't be better or worse than my rules, but they are different.

Fewer bugs. Good standards should minimize common coding mistakes.

Doubtful. I'm not going to make less bugs because I'm following someone elses rules. Now, I will make less bugs if I am following my rules, but it's unlikely my rules will match $WORK rules (again, not that one rule is better than the other - many coding standard rules have just one purpose: uniformity). If I have to do work to make live easier for someone, than that's not free. It takes me time, and I'll make mistakes I wouldn't have made otherwise.

Shallower learning curve and useful training for new hires -- if your standard mandates proven, well-known idioms and style from the programming mainstream.

More rules means there's more to learn.

Again, I'm not saying company coding standards aren't good. Sometimes, they are. But it's not clear-cut, and one should be well aware of both the benefits and the drawbacks.