Everyone is different here, but the way I got the most out of reading this code was by looking at each point, and thinking about how it applied to a situation that I had been in or heard about. After spending enough time doing this, I found that naturally when I encountered new situations in the wild, I'd think about particular points of the code that corresponded to it. I've found this useful not just for making decisions myself, but also for raising concerns to people in positions of power.
If you cannot think of case studies relevant to your own research or situations you have read about elsewhere, the discussion questions below may help, and you may wish to read them before reading the code in order to frame your reading.
Most of the code is, I think, about what one would expect. But there are some things I found genuinely surprising. I always disliked norms of confidentiality, but 1.7 convinced me to take it more seriously as a professional obligation. My personal favorite, though, is 2.3, which actually encourages you to challenge and in some cases break unjust rules. It's really refreshing to see that in a professional code. I also like 2.9, which makes a case for verification, and 3.6, which makes a case for automatic repair.
But not all verification work is inherently good, even though we often like to imagine that it is. Like what if your proof automation is being used to verify a drone used by the US military? This can be a major strain with 3.1, and yet this is where a lot of verification funding comes from!