(Personally, I have this feeling that my tasks tend to be varied enough that 'number of times done' would almost always == 1, however, I don't have any actual data to back that assertion up. (And maybe you used this to hone in on the "true hour cost of a 2 story point task"???)
In my estimates I was focused too much on development time and not providing adequately for testing and deployment. On an existing project with the procedures already well in place it was fine, but for new or new-ish projects I was always under-estimating.
The other thing was calibrating my margin of safety. I now typically estimate at 2x the time that I think it will take to allow for unexpected issues and unrelated tasks that always pop up. That also works for me with the expectations of the people that I work with -- the estimates are used for planning and coordination and aren't effectively deadlines, but if I underestimate too often is causes coordination problems with the business people.
Maybe something like "that's probably 3 loops and an email"
That's a couple hours for the loops... A couple more for the email, assuming HTML has to be dynamic based on a model with 5 values... Etc...
Sure it's not identical every time, but the patterns are the same.
It also depends on how much leeway your estimates can have: if it turns out to be waaaay more than two loops and an email, what happens? Does management just nod, or do they start "negotiations" about not paying for the work it took you over the "estimate"?
As an agency (maybe it's the same everywhere), I think there is wild external and internal pressure against giving accurate estimates.
When you get in the room with the project managers and the sales people, you can see their eyes rolling as the costs escalate.
"How long is implementing Google analytics going to take?" Maybe 3 days? "3 days really? That seems high, can we write in 2 days there?" Well we can, but it's still going to take the same amount of time.
Most of the objections I see to estimating are objections to their abuse.