Earlier quoted context omitted.
if there was an objective way to value the quality of a commit, rather than how long it took, then yes, this method of rating would work. The length of time is not proportionally related to the quality (it's not even inversely proportional - i think there's no relationship between time taken to do a commit and its quality).
Do you really think it’s impossible for a manager to rate a commit or completed ticket (including taking into consideration how long it took vs how long they think it should have taken). I don’t think many software developers would want to work under such a system. Yet we build them for other people.
if the manager is able to know how long something would've taken, it is because the task is simple and already well specified. Therefore, the work will be similar to delivery analogy from the OP. I do believe some places (such as oracle) do this sort of rating (heard from the grapevines).
However, most work i find that require a developer isn't simple tasks, but complex cognitive thinking to come up with a solution. I dont believe a rating system works for such work. Peer judgement, as well as long term results (such as a stable, working system that expands as required in a timely manner) work much better. But by the time the long term comes, the developer's contributions would've been diluted if the team expands massively due to success, or have moved on!