There are also multiple definitions of "good developer" (speed/output level vs maintainability vs project definition and architectural influence vs firefighting vs...).

That doesn't mean they're all what a company needs at a given time. This leads to another way you end up in hard managerial conversations: you're good at X, but the business has changed and Y is driving our bottom line much more than X now, but you have no interest in Y and are resentful that you aren't being rewarded as handsomely for X anymore. What do you do if you're a manager who knows the odds of X being that important again in the future are very low (maybe there's enough structure in place now with automated testing and such that firefighting is way less critical than it was when small), but the one-time-star starts complaining that their raises have gotten smaller as they've resisted coaching/directional changes for the past year or two?

And if you're completely transparent with salaries, you've got an extra problem: this person could be higher paid than some of the people contributing the most right now, and explicit specific knowledge of that will just make even more people unhappy, if you aren't in a position to simply raise everyone's else's pay to match.

Representative ranges (with room for overlap for e.g. someone peaking at one level vs just starting at the next) give you many of the benefits with far less of the ego bruising. Generally you-as-employee can get a feel for what these are after a couple years even without it being explicit, IME.