Parent post should be modded up. There is something to be said for using a rigorous methodology when comparing the value of different employees, and that will necessarily reduce to numbers at some point.
That being said, TFA is either seriously oversimplifying what its author learned, or the companies it describes are doing it wrong.
TFA is basically describing ways of developing and presenting sociograms. The shape of any sociogram is as dependent on the choice of qualitative tools used to develop it as it is on the reality that it claims to represent. To be brief, any sociogram, no matter how numeric its appearance, is qualitative and not quantitative and has a huge amount of observer bias built into it. It is a tricksy sideshow mirror that reflects an unstated bias and is inherently untrustworthy.
I've been trying to find a way to say more without ending up as tl;dr and I can't do it adequately. So here are some teasers:
The first steps to effective HR management involve developing good job descriptions of the existing roles. Performance measures can be used to determine how well HR has done this work: do those who actually work in or with each role agree with HR's description? The next steps involve reshaping the company as a whole by changing all of those job descriptions to support the new workflows. Some of this can be quantified: your employees represent a pool of very detailed knowledge about how the jobs could be done.
Only after the above is done can you start looking at employee performance, both current and predicted in the new roles. Very little of this is truly quantifiable: about the best you can do is to say "On a scale of 1 to 5, how legible is Mr. Anderson's handwriting?" And even then, recognize that some of the most critical information may be very hard to come by.
An example of the last: Do you know that you have an entry level programmer that everyone goes to as a technical resource because he has twenty-plus years of extensive experience leading development teams, but now he's satisfied with a low pressure day job to pay the bills while he writes his first novel in the evenings? His LOC stats are miserable, because he spends a lot of time with drop-in visitors who are wondering how he would approach this bug, or refactor that monster object, or shed some light on what the hell the guys who wrote this legacy code 15 years ago were thinking about when they used that schubert approach on what is clearly a brahms problem? You probably don't want to lose this guy: he is improving the efficiency of everyone around him. But he is not going to show up favorably on any of your metrics. And in a dirty professional field like software development, he and his kind are legion.