Sounds like you don't have a good process for handling scope changes. I should know, the place I'm at now it's lacklustre and it makes the job a lot harder.
Usually management backs off if they have a good understanding of the impact a change will make. I can only give a good estimate of impact if I have a solid grip on the current scope of work and deadlines. I've found management to be super reasonable when they actually understand the cost of a feature change.
When there's clear communication and management decides a change is important to the product then great, we have a clear timeline of scope drift and we can review if our team's ever pulled up on delays.
I feel like some people in this thread are talking about estimates and some are talking about deadlines. Of course we should be able to give estimates. No, they're probably not very accurate. In many industries it makes sense to do whatever necessary to meet the estimate which has become a deadline. While we could do that in software, there often isn't any ramifications of going a bit overtime and producing much more value. Obviously this doesn't apply to all software. Like gamedev, especially before digital distribution.
I think it's obvious that all software teams do some kind of estimates, because it's needed for prioritization. Giving out exact dates as estimates/deadlines is often completely unecessary.