First things first -- adorable blog re-design 
A related past discussion is Goals and priorities for C++, where we looked at one proposal for C++ principles. Diffing that with with Rust principles, I have the following thoughts:
I love that supportive is a separate, explicit goal -- the secret power of Rust is people (well, and the borrow checker sometimes helps), so it's important that we have a people goal of the list of language principles.
I am of two minds about versatile. Historically, I've always felt it's a shame that we don't have a "better implementation of OCaml", so that Rust can have a laser-focus on systems programming niche. But recently, I come to appreciate the "one language to rule the all" sentiment more -- today's software is big, and big means that it will necessary span all the layers, it will be both high-level and low-level. And, if you can do both in one language, that simplifies the system greatly. Over the last couple of years, I've migrated my scripts form bash to python to Julia to Rust. Rust is supposed to be the worst language for shell scripting, but, given that I get to re-use libraries, IDE support and my own knowledge, it ends up the most productive (but definitively more verbose in the number of lines of code).
I am slightly cautious in that I don't see a value that directly corresponds to "both software and language evolution" from the C++ list. To put it in other words, "don't do breaking changes" is something we very much do, but I find it hard to attribute it to a specific principle. It kind of is about productivity and reliability, but it also kind of isn't, at lest not in the specific way that principles are elucidated.
For the "how to rustacean", I feel that one thing is missing, which seems important to me at least. I'd put it as "you don't have to be perfect". That's a bit hard to explain; Rust is an open source project, and a lot of it is driven by volunteers, out of intrinsic motivation. Such mode of operation creates excellent results -- if you work on something because it makes you happy, and not because you have to, you make 10x impact, even if you spend 0.1x time. For many people, one of the easiest way to suck the happiness out of the work is to start thinking "gosh, I really could have done that better" or, worse "I should have done that better". It's important to show path to become a better rustacean, but I think it's important to make this strictly optional.
To give an example, let's say I maintain a project and I get an issue report before my first cup of pu'erh that makes my blood boil and makes me want to leave a curt RTFM response. If I score A+ on being kind and bringing joy to the user, I should proactively step in, emphasize with the reporter, diffuse the tension and get to the actual problem. However, by blood's boiling, so I chose to say nothing instead.
Now, if the values say just that I need to be kind and bring joy I might starting to hate myself for not being a perfect rustacean, or I might force myself to pretend to be one, and feel uncomfortable afterwards. I'd love to have an explicit allowance to drop the balls on the floor in the values -- I think I've been very successful at that, but it was a non-trivial deduction for me to realize that not being perfect doesn't make me a bad maintainer.
Here's another example. Let's say you send some PR with an improvement, and then maintainer asks you to change something. You say "I'll do that on the weekend", but you don't and postpone until the next one. Two weeks later, you still haven't done what's "promised", and you now want to reply "hey, I don't have time for this after all", but you should have done this a week ago. So you postpone not only the work, but that comment as well, and next week the situation is even worse. (that was the story of my very first PR to an open source project). I think it should be explicitly OK to just disappear from the PR, without notice. This actually makes leaving the notice easier, as now you don't have to, you just can, if that makes sense. This second example is "it's OK to not follow through".
That being said, that's more nuanced than just making the value optional. Some things you just shouldn't do, and, in the first example, leaving a mean response would definitely be a no go. Except that it's even more nuanced than that: people make mistakes, and it's OK to make them sometimes, if you acknowledge it.
So, yeah, I'd love to see something explicit along the lines of (but toned down quite a big):
You don't have to be perfect. These are the values which we think make the Rust community better. But it doesn't mean that you need to make the community better in every possible way, your personal happiness is more important. If you feel that some of these values don't align perfectly with the way you prefer to work, that's fine, as long as you follow the code of conduct.