Most people in the software development industry will (hopefully) agree that estimates are important. You need estimates to predict the cost of development and how long it's going to take. Without them, there is no way you could promise a delivery date to a customer or come up with a total cost estimate. Both of which are tremendously important when your core business is based on delivering software to clients. It is therefore very important to make sure your estimates are as good as they can be, and that you review your estimates with the final actual figures so you can figure out where you need to start improving (either your development process, or your estimation practices).
But there are some things you need to watch out for in any organization which takes estimates seriously. Most development shops have estimates at the task-level. These task-level estimates are often used during the planning of the next iteration, but were most likely also used in the initial total estimate of the project. I certainly don't doubt the importance of those task-level estimates, but i do think they should be used cautiously.
If too much importance is placed on staying below the estimates, or at least not going over them, you run the risk of growing a culture where developers let the estimates have too much influence on the quality of the work they're doing. Some developers will strive hard to routinely stay below the estimates. Some developers will work in fear of going over the estimate. In both cases, it leads to technical shortcuts that will be taken. Those shortcuts will consist of skipping some tests here and there, skipping a bunch of tests altogether, decreasing willingness to refactor code that could use it and worst of all, no longer keeping a clean design in mind. Granted, i'm painting a very bleak picture here but it does happen with some people and the negative results can not be underestimated.
Let's consider the overall effect of these shortcuts. A shortcut here or there is not abnormal in some circumstances, but it should be exceptional. It should not become routine, it should be frowned upon and i'd even go as far as recommending a "no shortcuts allowed unless the team approves of it" policy. A shortcut here or there doesn't take a lot of effort to fix and because of this, it can often be done as soon as the original reason of the existence of the shortcut (typically: a deadline) is no longer an issue. An accumulation of shortcuts however leads to not only an obviously bigger workload to fix all of the shortcuts, but it also impacts a lot of other code that shouldn't have been impacted in the first place. Once this happens, you've got yourself an unhealthy code base and it's only going to get worse until it eventually dies at a younger age than it could have reached.
Now, imagine a culture where estimates are given as much importance as quality. If you're approaching the estimate and you've still got a lot of work left to fully complete the task (and with fully completed, i really don't mean watching it work on your machine as you manually test it), then you consult with the rest of your team members. Estimate how much time it would take to fully complete the task, and see if the increased time over the original estimate is doable. If you're already behind your overall schedule, it's probably not doable unless there are many subsequent tasks that are dependent on this particular task. But if you're ahead of schedule, you're probably better off accepting the fact that you're going to go over this task's original estimate in order to do it right. If you do so, the extra hours you spent on this task should (in most cases at least) not lead to extra hours on future tasks. Conversely, if you've finished a task well below the estimate, it might actually be a good investment to refactor some 'bad' code that you've come across while working on your task. Or to add some missing tests here or there. That certainly doesn't mean that you need to spend all the available remaining time you have but you shouldn't run to start on a new task as soon as humanly possible either. Follow the boy scout rule here... you won't spend that much extra time on it, but overall quality can improve greatly from this.
In fact, i'd even bet that the time it takes to do it right will in a large majority of cases still be less than the sum of the original time that was spent on a task hastily done and the time that will be spent on bugs that resulted from that hastily done task, not to mention the impact it could have on the development of future tasks simply because of the suboptimal implementation of the hastily done task.
Finally, it's also important to think about why there was a need to go over an estimate. There can be a variety of reasons for this, and one of them is that the task was simply badly estimated. If that indeed turns out to be the case, make sure that you learn from it to prevent this from happening in the future. When we find bugs in our code, we try to prevent those bugs from ever occurring again. We should have a similar attitude to our estimating practices as well. If an estimate was simply too low, make sure that a similar task in the future won't be estimated too low again or you will again introduce a possible problem in your (future) project.
And that, in my opinion, is also a good reason to decide to go over the estimate if you can. If you go over the estimate and all people involved learn from the bad estimate, then everyone basically benefits from it. Future estimates should become more accurate, and no code was harmed in the process. You might have lost some money on it, but at least you only lost it once instead of losing it over and over again in similar future circumstances.