A Look At Your Theorems
"Hungarian Notation exists to make up for bad coding practices"
Whilst it's easy to ridicule the names used in Hungarian Notation, I note that your article actually fails to include any form of proof that the basic idea itself is bad.
In a general sense, it's just a naming convention. The right naming convention is very useful for making code significantly easier to read.
For example, take libraries (such as GDBM) that prefix their function names with 'gdbm_'. That's just a naming convention, but it's an absolutely essential tool for carving up the cluttered namespace effectively and safely.
For example, take languages (such as PHP) where variables are not declared. Using prefixes on variable names (l_ for locals, a_ for functions, gl_ for globals, c_ for data members, and so on) makes such code a lot easier to read.
Personally, if I was ever to meet Linus, I'd have to thank him for coming up with the best reason ever for schemes such as Hungarian Notation. His famous objection to the use of Hungarian Notation is that, when you change the type of a variable, you have to go through and edit all the source code where the variable is used. That's actually a superb reason FOR the use of Hungarian Notation. If you change the type of a variable, should you not actually check your code to ensure that the new type isn't going to break anything? And if you don't check, isn't that unprofessional behaviour, because you're now guessing something that it is perfectly possible to check and be correct about?
In your "discussion" of Theorem 1, you mention the idea of wrapping even supposedly standard functions to assist portability.
As someone who maintains highly portable UNIX software, I can personally testify that this approach is sometimes necessary (and that's before you look at porting to non-UNIX). Even on UNIX, many of the "standard" functions are buggy from one vendor (or even one release) to the next, and such wrappers are an excellent way to deal with this. In an ideal world, they wouldn't be needed - but this is RealLife(TM), and practical measures are what it's all about.
I'd also question the professionalism of the "annoyed" engineers. IT staff are (in the main) highly-paid professionals. They're paid to do a job, not be prima-donnas. Unfortunately, management exists to make stupid suggestions - after all, some manager at some time must have promoted the current lot to their over-elevated position - and the IT *professional* is paid to be just that - professional. To do a job.
Many of us would like to be artists, but we're not. Most IT staff aren't even any good at their job. (Not a popular statement, but unfortunately very true.) The vast majority of programmers I've met and worked with in my career are certainly not qualified or capable of determining HOW to write a piece of software. If they were, software would be delivered on time and on budget. The OpenSource world wouldn't be littered with the remains of v0.1 releases of software that never gets completed.
"Coding standards for style are a temporary necessary evil, but they should be restricted only to the alignment of source code, and not extend to naming or organizational issues."
Temporary? Why are they temporary? What will replace them? Better educated programmers? And where are these programmers going to come from? The quality of IT teaching is currently decreasing, not increasing, and many posts these days do not require any formal IT qualification. There is a shortage of programmers (I refuse to use the term engineer for most of these people), and that only lowers the entry standards.
I cannot see any "institution or group writing software" putting forth a "general form of commonality in the style of writing code". Such achieve agreement, such a style would have to be so general as to be ineffective.
Styles are designed not just to reflect best practice, but also to reflect the needs of the organisation. For example, go to a sweat-shop software firm that specialises in one-off bespoke projects, and the standards there will be high-quality and detailed, perhaps because the staff turnover runs so high. (Okay, no perhaps about it ;-) Go to a famous name computer company, especially one of the older ones, and the standards there can be low-quality, partly because of complacency, and partly because their work is research-driven (and getting researchers to work to standards is an exercise in futility at times.)
Restricted? Why? I don't see an argument supporting your theorem.
Coding standards exist to ensure that everyone in a team is producing code along the same lines. Strong, high quality standards are part of the framework (that includes proper designs and specifications) that allow managers to easily move staff around teams within a project, and even replace staff as and when necessary.
Good standards also have practical purposes, such as ensuring common coding mistakes are clearly documented (and therefore avoided), ensuring that developers know how to create a new module (eg which directory to put a library in, what the header files should be), and document the standards (as in quality of work) that your developers are expected to aim towards.
They also have the excellent role of being part of the framework that ensures that your senior developers cannot hold you to ransom. How many companies have you worked in where some of the senior staff are senior not because they're actually any good, but because they have some piece of knowledge which everyone else has to rely on?
They take the guesswork out of the process. Why have to guess how things should be, or even make things up on the spot, when you can write down what they should be? This approach is part of the work necessary to ensuring that you produce high-quality software through judgement rather than through luck.
Accept the principles, for they are with merit. Do all you can to defeat silly details. Be open to the benefits of any idea before you dismiss it. Try it out. Most ideas can only be appreciated once you've used them in anger, and at scale.
Guesswork is such a major cause of the low-quality work that most computer programmers output these days. Eliminate the guesswork, and the quality goes up.