I worked in an environment where we gradually moved from "one person, one module, one editor" toward something closer to a free-for-all anarchy. Part of QA always had a peer-review component, so it was imperative that everyone could follow other people's coding style, even before they then needed to work on it.
Nothing caused bigger problems than the tab-vs-space argument, especially when compounded by some people's desire to use a 4-space tab in their editor. Where to put the closing "}" bracket was a distant second place.
In the end, we learnt that the best answer was to force through a single coding style (for the complete code) that specified spaces. Editors could be used with the tab key, but set to an auto-indent mode that added space characters not tab characters, and aligned at 4-character intervals. This really helped everyone, from the smartest down to the weakest junior team members.
Like @7LM, the circle turned as integrated development environments became more capable. The problem of displaying indentation is then left to a smart editor.
The battle in the middle, it turned out, was really between a team taking collective responsibility for quality vs individual ego. And, in places, it was quite a battle.
How does that relate to the difference in salary? I wonder...
For a software organisation, there is nothing more important than the quality of your software, and the QA process you choose to follow.
In this context, then, perhaps that difference of salary is explained by how much of a team player you are, and how much emphasis you and your team collectively places on QA. Those who can subsume their ego into a best practice that is understood by everyone might just go further in the organisation, and get paid more.