I disagree with your assertion that inserting space after 'if', 'for', 'while' etc is universal outside of Plan 9. I have never adopted that convention, and it looks ugly to me. That is probably because I learned C by reading the Unix kernel source code (6th Edition) which displays a preference for brevity. If you go back to Denis Ritchie's original C reference manual from 1974:
you will find he was inconsistent - sometimes adding a space, sometimes not. Perhaps that is why there is no universally accepted style standard. If I had to justify my preference, I would probably say that if the round brackets were optional (as they are, for example, in pascal), then I would put in the space because they would be part of the expression. But I suspect my preference is mainly just habit and now my brain is wired for it. Richie does omit the space before brackets in a function declaration/call, and to me that is more consistent with omitting the space in other language elements which require a parenthesis after a keyword or identifier.
I am not sure that there is always a (logical) reason. If the language does not mandate a style, then whatever you choose is valid. Most of the time it boils down to what you first encountered when learning the language. Once you get used to one style, source code becomes much harder to read if it follows a different style, so you need a good reason to change. It makes sense to be consistent within a project, so unfortunately it is sometimes necessary to put up with a different style. Generally project manager or company will arbitrate on which wins. I am normally in a position where I am the only one working on particular source files, so I convert them to my preferred style, and then reformat them according to the dictates of the project when I am finished.
Sometimes there are arguments for a particular style change, like putting lvalues on the right of a binary comparison so that accidental use of an assignment operator would generate a compiler error, but
to me the result is so ugly, and my days of making that sort of mistake so far in the past that I definitely prefer the standard idioms. I have changed from putting curly brackets on the same line as the if/while/for
etc, because I find the structure of the program easier to read if the brackets line up with the opening bracket over the corresponding closing bracket. It seems more consistent with curly brackets around function bodies, it is easier to find forgotten parentheses, and I think the rule about spaces before braces becomes irrelevant. The only down side seems to be taking up an extra line.
I am not so keen on the braces around single line blocks - I suppose two wasted lines must be exceeding my tolerance. I sometimes make an exception for nested if/while/for etc statements where, for example, it may not otherwise be clear which statement an 'else' is associated with..
The Plan 9 developers obviously decided it would be better to establish a standard early on, and I suppose unsurprisingly the majority followed the traditions of the Unix source.
I am not sure about the rule on automatic variable initialization. That is the only one in your list which puzzles me.
DigbyT