If you go to shows or conferences, showing or talking about something is the best way to have something, and the deadline focuses you like nothing else.
(that said, sometimes I wonder if I would have something much more polished with a last-minute magical 2-week reprieve)
The same applies for a personal project that's delivered as a gift to a family or friend. I guess I should write sometime about the Raspberry Pi-based Christmas present I gave my father in 2014, even though he stopped using it scarcely a year later. For this thread, the point is that the deadline made this the only personal coding side project that I've completed in several years.
In practice there are often complications, however.
Usually, it's just office politics: Those cases can be quite difficult -- you really need buy-in and TRUST from management (and have to do the right political plays, etc.) to be able to cut through the bullshit and "allow" feature slips. Books have been written about this scenario.
Rarely, deadlines are imposed by Real Politics, aka: law... which can make for Interesting Times. This can range from "quite difficult" to "too easy!", so I have no advice here.
What happens when your software is in a broken state that's worse than what you had before?
I am also a strong believer that it is a sign of gross lack of internal discipline, or at least severe lack of confidence. It means you still suffer from "unknown unknowns" and therefore can't come up with and stick to a proper estimate (even if it is something broad, like Q2 2019). This doesn't say good things about a software team, in my opinion.
I know very well that estimates are difficult. But, again in my opinion, going with "we will release the next version on February 20th, now let's discuss what features we can implement during that timeframe" as opposed to "here is a list of features we want in the next version, now let's discuss when we can finish them by... actually never mind, we will just tell people 'when it is ready'".