1. Coordination with other teams or real-world events. In most decent-sized companies there are many people involved in a product or feature launch: product marketing, brand marketing, support, not to mention other dev teams. Many times these teams will need to broadcast external, hard dates (e.g. "our PR firmed lined up exclusives with journalists on date X") Being substantially late can affect lots of other people. However, importantly, this is not always the case. If you're estimating for the benefit of coordinating teams, be very explicit about which other teams depend on your estimates, and why.
2. To prioritize and decide which features to build. Prioritization is solely about balancing expected benefit with expected cost, so if you're wildly off about the cost, your time may have been better spent building something else. Again, though, if you underestimate by a bit, but in the end come up and say "I wouldn't have really worked on things in a different order anyway" then nothing was really lost. I can definitely think of cases, though, where if I really knew how long something would take at the start I would have chosen to do something else, or at least do it in a different way.