The big difficulty is that salary gets really complicated, really fast. It helps many people, but building the system that is equitable would be difficult, and all the positive outliers could be harmed in the process.
SCENARIO: Money is a little tight but applicants are plentiful. We interview lots of people, and three of them look very qualified and are willing to work for a certain wage in a tight range. All hired. Three months later the group discovers a unique need, needing a developer on a specific tool with specific skills. They'll be hired at the same job title, but because the group need a specialized skill immediately, they will go through a headhunter and ultimately pay a premium for that fourth worker. Now, because all four have the same job title, the critical question: should the company go back and increase the three other workers' pay to the same pay rate of the fourth worker with the specialized skill? Should they refuse to hire the specialist at a rate above the other three?
In some fields it can make sense to standardize pay. Most skilled trades operate this way. There is a standard rate in a region for a Journeyman with specific certifications. Trade unions can help fight for specific benefits. You know that this class of tradesman has a specific skill set and can be hired for $27/hour. You need four of them. All of them are treated as interchangeable.
In other fields it can make far less sense to standardize pay, mostly because there are many variables. Unfortunately software development is one of those fields where it is complicated. It would be really convenient -- both for applicants and employers -- to have such a scale. This is a Java programmer with seven endorsements certified at grade 27, so pay is automatically $x.
But unfortunately for this field, technology is ALWAYS changing, so the scale would be difficult. You were certified in version 3.2, but the system has moved on to version 4.1. Does that individual lose the old certification? If they take the new industry trade group's course do they now have 8 certifications instead of seven? Do certifications expire over time, or transfer between technologies? With the huge number of technologies out there, does that mean we'll have thousands, perhaps tens of thousands, of different certifications for the trade union? How are individual certifications weighted, and how are they equivalent? Is a master Direct3D 12 certification the same value as a master PostgreSQL 9.4 certification? Is a PostgreSQL 9.4.4 certification valued differently than a PostgreSQL 9.3.9 certification? If someone has certifications in other specializations, must those apply in the cost? With the rapid pace of an enormous number of technologies, what prevents someone from getting hundreds of certifications? Such as "I've got 47 certifications, one for each version of the software released over the past two years"? While it works good for slower-moving trades, it does not work so well in software.
Sometimes I feel it would be nice to have programming trade unions. There are many features like collective bargaining for benefits that could be nice. But for actual salary levels, union-based standardized wages would be a nightmare. It would add a convenience factor to ensure new workers have certain minimum competencies, but it unfortunately adds maximum values as well. Nobody wants to know that they could be making more due to market pressure.
By establishing fixed buckets of pay levels, it establishes both a minimum (yay) and a maximum (boo) within a region. If you've got any kind of specialization or exotic skill -- and many of us do -- those same pay buckets that help many people also hurt the top performers.