This is how you get lots of low-hanging fruit pickers, rather than programmers who would rather solve hard problems for more significant, but less visible, business needs.
Examples: Refactoring is effective in the long-term but doesn't look as good in the short term. Exploratory work often takes time but doesn't show any specific productivity. Teaching and helping others is incredibly value, but increases their productivity rather than your own.
Evaluating programmers by their business output leads to low-quality code run by a team that doesn't talk to each other and loves self-aggrandizing. Also when something big finally does slip through the cracks, everything will fall apart.
And if you want to find outliers with it, good luck - they'll make mountains out of their molehill of work.
Honestly, it's not very easy to get good metrics for programmers - for the same reason it's not very easy to increase programmer productivity on a project. It's not easily divisible work and involves a lot of teamwork.
I've heard 360 reviews work pretty well though.