I think these are all good points when it comes to writing technical documentation, but with naming things in code there are a different set of problems.
You can't hone your approach for a specific type of audience, because you can't make assumptions about who'll be reading it.
I think we can assume they're technical, and that they're proficient in the language the code is written in. Maybe we can't really assume they're familiar with the project, they could be new to it; but I think it's fair to say they're willing to be invested enough to become familiar.
--
The way we name 'things' in code, allows the reader to infer more about that 'things' place, contextually, within a larger structure.
* How can I indicate what this structure contains?
* How can I show why I have chosen this approach?
* How can I show how this section of code relates to the larger code base?
* Does this 'thing' relate to a larger structure?