These are great guidelines! I also do a lot of performance-related work and I've seen people stumble over basically every area you mention--especially the "design first, think about performance later" stumble.

The only quibble I have--which Bentley also quibbled with--is that simple code is faster. It's usually not the fastest. Usually there is a complex way to increase speed. But the question is: do you actually have time to find it? It's easier to understand the performance characteristics of simple code (and sometimes easier to test, too). It's less likely that you will use an abstraction that isn't truly zero-cost. It's more likely that the simple code will be amenable to compiler optimization, also. It means you get a pretty good solution before you give up and work on something else. But it's usually shy of the best performance possible.

For instance, if you're parsing strings, it usually will run faster when you write complicated logic to keep a bit of lookahead buffer in registers (assuming lookahead is needed--if you can dispatch parsing off a single character, it doesn't really apply) and maybe keep track of which tests you don't need to run again. But it's much easier to forget the failed branch, re-read the string again, test again, check bounds again, and all the rest--the logical dependencies are vastly simpler.