This is a point of view and your criterions may be good.
According to me there is no "A" rule, but it's in a context.
The bit type is effectively a bad example from a previous compagny I was. I'm not using bit types and I've removed it now.

There is limitations of course. For instance in my compagny these rules have been adopted by all the embedded programmers but not by industrial programmers (Visual Basic, Visual C, ...) because the rules were not applicable to them.
The idea isn't to give restrictives rules and to oblige people to follow it. The idea is to give basic rules to keep a good process when designing code. They have to be adapted to the context and improved all the time by taking into account new constraints as you said.
The bit example is finally good example because it has been removed from the rules when we've identified this was not applicable on all targets...

More generally, the rules I've wrote in this document are mostly refering to the process, you will agree I'm sure. And I recognize they're still not perfect and usable as it but have to be improved...

In my document, the introduction says that these rules are probably not the best ones and can be improved all along the project...

Regards
Stephane