[tikhonj]

Seems like there's a structural issue at play here: the team is accountable for building a specific set of features at a specific time. High-level functionality is fixed and the timeline is fixed. If the estimate is off or something unexpected comes up, what's going to give?

Answer: everything else. Anything that the planners and executives didn't consider ahead of time. Other aspects of the work: code quality, product design, accessibility, performance, robustness, edge-case-handling... Team learning, culture and satisfaction. At the limit, the team will compromise on anything that you don't need to claim a feature is "done" with a reasonably straight face.

It's simply not a good system even when the estimates work out reasonably well—and, empirically, they usually don't.

To be fair, this isn't entirely the fault of estimates in general or this estimation approach in particular; I believe those contribute, but it's primarily a reflection of how the company and culture are structured. If you're already in a system like that and you can't change it, trying to do estimates well might be the best option forwards, but only because you're already in a corner.