I think this works, but only in cases where two things are true:
- the team is actually responsible for the date—often, there's massive asymmetric pressure to aim for less time
- if it's an actual deadline, the team has the autonomy to adjust scope to hit it
In my experience, the worst situations happen when estimates are treated like deadlines. An estimate has to have uncertainty. Without some way to manage uncertainty, you'd have to pad estimates out to like the 99th percentile to hit them consistently, but people read estimates as averages and push back against that. If teams are consistently going over estimates, it's a problem in how you do estimates, not how you're working. (Which is also why evaluating people's performance based on how well they hit estimates—which seems common on a lot of teams—is completely misguided. Estimating is a nice skill to have, but it matters far, far less than the quality of the work people actually do!)
On the other hand, a deadline is only a deadline if you're willing to adjust scope to hit it. If there is a real deadline and it looks like we might not hit it, the answer isn't "try to be more productive" (which is all that "work harder" actually means!). Instead, we should figure out how we can change what we're focusing on and what we're concretely building in order to still hit the underlying goal as well as possible with the time remaining. If we're working towards an estimate rather than a deadline, we might still adjust scope and focus, but the first step would be adjusting and sharing a new estimate.
But if the culture is that estimates are hard commitments and you can't adjust the scope or the timeline, the work environment is going to be absolutely miserable, people will get stressed out for no real reason and the quality of the work is going to suffer. People will do whatever it takes to technically achieve estimates, even if that means cutting corners everywhere, sweeping bugs under the carpet, not spending any time to iterate or improve on the system and indefinitely putting off engineering work that has a small cost now but gives a massive medium- to long-term benefit in productivity. A month or two into this process and you move towards a death march that burns everyone out and, on the time scale of months, accomplishes substantially less than a less aggressive approach would have.
I'm currently working with a team that has this problem to some extent—of course, the managers think of it as "accountability" and "a focus on delivery"—and in a bit over a year, they've built a codebase that already feels like a legacy mess, while accomplishing what would have been like eight months' worth of work with a better engineering approach. It's pretty frustrating to see and I'm trying to change things, but not sure whether I'm going about it effectively.