4 reasons Agile Story Points > Hours

1. Velocity
1. Normal velocity = d/t. Wouldn't make much sense to measure distance in hours. You'd get t/t.
2. You need a measurement of work (which corresponds to the measurement of distance) to divide by time and get a measurement of Work per Time.
2. Time estimates are relative (to the engineer)
1. Measurement of work is empirical. Doesn't matter who's doing it. 
2. It's a measure of the work to be done, not the time it takes to complete.
3. When estimates go bad
1. If you've been estimating Stories in hours, the response to underestimating is too often:
1. Work more hours (which increases the numerator in the t/t ratio, right?), or
2. Work faster (which decreases the denominator in the t/t ratio, right?)
2. If you're properly estimating by Story points, the response is:
1. Adjusting your estimates or
2. Adjust your velocity.
3. The net result of all this is the subtle creation of the assumption that the engineers are in fact motivated and talented to work to their capacity without strict oversight. The option to mandate more work in order to correct team product output is quietly removed.
4. Story points are the only work type that is measured in story points. Story points are also, not coincidentally, the only unit which is counted as progress toward project completion. Since, as an agile team, we agree to deliver a functional product, rather than to work a set number of hours, the amount of time we work is of no relevance. It doesn't count to project completion. But story points measure the amount of functionality added to the project.
1. My measuring stories in points, and other issues in hours, you ensure that those other issues (like bugs, or improvements) do *not* count toward project completion. 
2. This is critical in calculating your velocity. If you spend half your iteration fixing bugs introduced from the previous iteration, you will have only the remaining time to work on stories. This will reflect in your velocity, and you will therefore be correctly informed that your poor quality is affecting your forward progress.
3. By contrast, a team which writes quality code the first time (and therefore does not use up their time with bugs) will have more time to add forward progress (story points) to the project.