In my experience, people are only _pretending_ to ask you to justify estimates. In reality, they are just angling for a discount and/or rush job. It's just a technique for increasing anxiety.
The software is being written for the customer and/or management, and they're paying for it. They have a legitimate right to know why the estimate is what it is, and to understand what work is going to be done. If they want to exclude parts of it because they don't see the value, then that's up to them because they get what they pay for.
If you can't explain why it's a bad idea to cut certain parts out, or why certain things take the time that they do, then it's a failure on your part as the engineer, and not theirs.
That's what expertise is sometimes like: an accurate gut feeling, impossible to articulate clearly.
You don't have to articulate it clearly, you don't have to know why you are making the estimate you are making. It's ok for management to push, in fact it is their job.
I suggest this book. https://www.amazon.com/dp/B004IK8Q22
If nothing else, management will be more trusting in those situations if you give good and accurate estimates the rest of the time and are able to justify them.
I recommend not default-reacting to "why does it take so long? Isn't it just A, B, and C?" as an expression of pushback, but rather just as an expression of honest confusion.
And I do agree with OP: every company does this. They want to squeeze every bit of work out of you, and this comes in other forms, not just through 'agile estimates'. Communications across teams that emphasize 'work-hard play-hard' also fall under this, and the 'play-hard' never actually comes. It's just new time-crunched work that gets dumped onto you. Or 'move-fast teams', or 'OKRs', etc.
The entire corporate infrastructure and communications is designed around pressuring workers to work more and more. Sure, there might be some great managers that can push back, but how many of them have you encountered across all the jobs you've been at? Most of my experiences have been what OP has said, most teams are terrible.
It's not a coincidence that the Tech Burnout Index is almost 43% across all of tech. Which means any job you jump to will have a good chance to burn you out some way or another. Which means all the crap that developers experience that burns them out is nearly ubiquitous, including being constantly grilled on estimates.
Burnout Index: https://f.hubspotusercontent30.net/hubfs/7677235/The%20State...
If that conversation is happening with senior management, it can also identify some consistent mismatch between their perception and reality. (Didn't your team get 5 new hires last year? Yes but two are on leave and we also took over responsibility for customer-facing documentation from marketing). Or reveal new priorities when consistent themes come up -- maybe the testing process is being slowed down by a growing matrix of product configurations, and management had no idea how much work that creates.
When the language shifts to something like "regardless of your estimate, we need it done by the end of Q3, so make it happen", then I treat it as pushback.
This has been how I handled issues, yet I'm getting more convinced that it is not productive.
People don't learn through only repeated exposure. In the second time something happens, they should be reminded of the first time. And in the third time, they should be outright denied any explanation with a reminder of the first two incidents. Otherwise, they'll keep doing the same thing, probably because it's very low-cost to them, and I'll keep spending my precious resources.
In my experience, they definitely don't know. But no amount of explanation is going to do it for them; any explanation is going to be met with stuff like "well, there must be a simpler way", which is a hell of a statement when it comes from someone who has no idea what they're talking about.
And oftentimes, at the point where you're making the estimate, you don't know how long "A, B, and C" are going to take. You might know how long they will take if the system underpinning "A, B, and C" do their jobs, but they inevitably won't do their jobs, and the extra time is usually working around the failings in systems that you have no choice but to use.