I know this thread is a little old now, but as a developer at Pivotal, I don't completely agree with any of the existing answers.
The philosophy behind not estimating bugs isn't that bux fixing doesn't deliver business value, it's that introducing a defect into the app and then fixing it does not represent net forward momentum.
For example, let's imagine that two teams are implementing the same feature set on iOS and Android. The iOS team has bug/chore estimation turned off, whereas the Android team has it turned on.
The iOS and Android teams both estimate the same story at 2 points. They both finish the story in the same amount of time, but in the next iteration, it turns out the two teams have introduced bugs with their implementation.
The iOS team has only introduced one bug. They fix it in an hour.
The Android team has introduced three bugs, and assigns them one point each. It takes them a day and a half to fix them.
The iOS team is moving faster than the Android team, but Android's velocity is now higher. This throws off the planning of future iterations, making it appear as if the Android team is moving more quickly towards a viable release, when in fact they may be introducing bugs into their implementation at a faster rate than the iOS team, and therefore accomplishing their goals more slowly.
Sometimes, however, there are defects which were not introduced by your team. Maybe it's a legacy codebase, and the defect is as old as the hills. In this case, it doesn't make sense for this story to drag down your velocity, and you should probably log it in Tracker as a new Feature, rather than a Bug.
Of course, it's ultimately up to you how you want to do story estimation. I've worked with a few teams who had bug/chore estimation turned on, although I personally prefer to have it turned off. Tracker won't judge you!