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.
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.