We always do code review, so no one goes too far off the reservation, but you accept diffs that are acceptable in their own context; values disagreements are nonblocking.
Lots of people emphasize the "what"/"why" when talking about software engineering ethics, and lament that everyone only ever talks about the "how". I think that view kinds of misses the point. The three questions are rarely completely separate. Plus, for most engineering projects most folks will work on throughout their career, the "what" and "why" are extremely straight-forward and at least relatively uncontroversial. The "how" (good security, good uptime, etc.) is by far the most important question.
The use of the word “agree” suggests that the article says the thing you say you don't agree with but it doesn't.
The importance (to be fair, absolute importance is probably more important than ranking here) of the questions is important to ubderstabing how much you can or cannot accept divergence in the subject matter of each question between your preference and that of (or imposed on, for those where the decision comes from outside) the team.
And the same works in reverse for the team’s perceived importance of each question and their ability to accommodate/tolerate divergence from you.
So understanding the ranking, yours and the teams, is important to understanding fit, but fit isn't driven by alignment of the rankings (in fact, to the extent that there is disagreement in preferences, it is ideal that your importance order is inverted from the teams—that you are flexible where the team is inflexible, and vice versa.)
As I see it, finding ways to accommodate the different goals, outlooks, and personalities that make up the team is one of the team leader's responsibilities. After all, there's not really much need for leadership if everyone is the same.