My firm has always maintained strict standards regarding code formatting, organization and commenting - to such a degree that new staff inevitably second-guess their employment while acclimating to our rigid standards. The result, though, is code that's easier to read and maintain; it's become a mark of quality for us. This philosophy is maintained in our production department; long before such standards became enforced by XHTML, for instance, we required explicitly closing all tags, case sensitivity and quoted identifiers (for example). And that's not even touching the formatting, naming conventions, organizational principals or other practices that I feel really demonstrate our commitment to extensibility and maintainability. Additionally, we've maintained strict standards and a sophisticated library for templatizing markup so that it's effective centralized, separate from the data from the presentation layer and thus greatly simplify maintenance; this is one of the key selling points that routinely wins us contracts.
Given this, I may seem like the person least likely to criticize standards zealots. Nevertheless, it's gotten to a point that even hearing the terms like "web standards" or "semantic web" makes me cringe. It's not that there is anything wrong with any of these concepts (quite the contrary), so much that many of their proponents have become so mired in their principals that they've forgotten their objectives.
The most obvious example of this is the so-called "Holy Grail" of CSS Layouts. This goal of this is to create the cliché three column layout with a fluid center - but without using tables. If you search Google for "Holy Grail Layout CSS" you'll find hundreds of approaches to this problem, many requiring dozens of lines of CSS, convoluted hacks or even javascript to dynamically resize elements. The challenge of this is not lost on me nor are the benefits of using <div /> tags in place of tables - but when you find yourself writing twenty lines of code to replace what can easily be handled by a four line table then it's time to step back and evaluate your goals. If you're building an application that needs to be skinned by third-party developers then the overhead may be worth it; if you're using a template-driven preprocessing engine, however, and have no need to independent skinning of your site then you may be complicating your markup for no benefit outside of stylistic integrity. Admittedly - Matthew Levine's approach is really quite elegant and is quite similar to a tableless approach my firm uses extensively, but it's the crowning achievement of a crusade that in almost every instance has proven hypocritical to the mission of standardization (e.g., simplicity, readability, compatibility, etc).
On the note of compatibility, another example of this is the producers who, in the name of standards, rushed towards XHTML strict when it was first proposed - and in doing so completely disregarded compatibility with users' many "older" browsers (at that time those browsers were still contemporary). One of the most important promises of standards is the ability to write code once without having to play a juggling game of hacks to ensure consistent rendering - but that promise doesn't mean we're there yet. Ultimately, the doctype should always be a factor of client requirements; if your clients require compatibility with older browsers then XHTML strict is a huge step backwards. When we moved Ignia to XHTML Transitional as our default doctype and later to XHTML Strict it was celebrated by our production staff as "catching up", but in reality it was a statistical decision made according to our clients' demographics.
The bottom line is that as important as standards are their ultimate goal is to ensure consistency and simplicity. Standardization should never trump client requirements (such as compatibility) - and if it requires considerable overhead to maintain compliance then implementers need to evaluate what benefits those standards provide. Fortunately the technology has matured to a point where we have the luxury of accomplishing all of these goals - but as my firm takes on more mobile projects I'm reminded of these old feuds as we're again forced to compromise between ideal and real.