I have a simple rule of thumb: a deadline is a "real deadline" if I would reduce scope to hit the deadline.
A deadline is just a goal if I would not be able (or willing) to reduce scope to hit it.
Treating a date as an absolute deadline without being able to adjust scope is where productive work gets totally derailed.
It's all about weighing everything and making the right trade-offs. Sometimes short term solutions are the right approach, maybe you need a POC more than a polished product to get that next round of funding or something.
I've struggled with that in the past, and next time I'm presented with this kind of project, I'll clearly explain the trade-offs, for example translating lower quality to: this may increase the number of bug reports significantly, increase the maintenance cost, prevent the addition of other features with significant overhauls, this and this engineer may start looking for another job, etc.
It's also what most "agile" environments end up turning into: a bunch of inflexible arbitrary deadlines designed to make developers work more, amongst many other problems.
I forget who I saw do this (it may have been Nat Pryce at a talk somewhere). He took a list of the items that needed to get done. He rendered the first item with full opacity. With each subsequent item, he reduced the opacity. At the end of the list, the items were invisible. Then he said, "This is roughly the likelihood of me getting these things done."
It's a mistake to draw a line on your list where you think the deadline will fall, because then you are fixing your scope as well as your time. But if each day you adjust the opacity of your list, hopefully people will get the point.