My takeaway from the article was exactly that: if you document anything, document the WHY, not the HOW. That way, when the HOW changes with time, the WHY will guide its new form.
Agreed on the quality of the article. As always, Rands manages to put the right perspective on the topic. I'm forwarding to quite a few process-averse folks I work with.
Should I aim to explain the values that we're upholding (code quality, documentation quality, test quality, etc.), in every step?