This certainly doesn't apply to the domain of critical-systems software engineering. I realise the emphasis of the article is meant to be agile methods, but the claims made seem quite categorical, and they don't hold up.
The most well-known coding-standard of this sort is MISRA C. NASA has one too, as does the Joint Strike Fighter project, and there are plenty of others. When these standards are taken seriously, developers aren't permitted to treat them as mere guidelines.
Plenty of organisations may be sloppy with their enforcement of coding standards. It's also possible for bad standards to be actively counterproductive. That doesn't mean they're always misguided and always impossible to enforce.
> The problem with abandoning the fear of failure is that it requires trusting our developers, a lot.
I defer to an excellent article on critical-systems software development: 
> the culture is equally intolerant of creativity, the individual coding flourishes and styles that are the signature of the all-night software world. “People ask, doesn’t this process stifle creativity? You have to do exactly what the manual says, and you’ve got someone looking over your shoulder,” says Keller. “The answer is, yes, the process does stifle creativity.”
> Real software quality is not a set of shared rules, but a set of shared values.
There's a reason avionics software development does not share this contempt for rules. Of course, there's far, far more to building life-and-death software than just following a coding-standard, but still.