I've been on the software company side of these conversations with customers many times.
I've had to tell customers that a certain feature/function/capability is deprecated, or will be deprecated, and that they need to plan to change how they achieve a certain outcome in their environment that is dependent on said feature.
The customer can only see things through their eyes; their specific need, the challenges they have in changing (technical knowledge, time, cost, etc.), why is the software company 'forcing them into this' (sometimes these deprecations have years of advance notice... but to customers it is usually 'short notice' because they choose to ignore, or just procrastinate on, the advance warnings..), why can't this feature be retained because it works fine as is, etc. etc.
I get it. I've been the customer and been in their shoes. Many times.
What the customer doesn't see is that these large software companies have a lot of telemetry data over how their software is used. They know what percentage of their user-base is using different features. They know how much support effort a feature is generating (costing) them. They know how much it is costing them to maintain that part of the software. That all goes into these decisions. On top of that , the software company has to look at this at a global level, while the customer is just looking at it from their individual perspective. I won't say that this is a 'greater good' type thing... but that's good enough an analogy.
The software company will often deprecate a feature because they have already developed and released a better way to achieve the same outcome, and they want customers to adopt that new method, not stick with the old one. The new method/feature might be faster, more resilient, more reliable, more secure, etc. but you'd be amazed how often customers just say "yep, on paper I totally get it, but changing stuff is hard. It costs me time, effort, manpower, etc. and I have other fires to put out". It's frustrating, but understandable.
Then of course there is the issue that the new feature might not be a 100%, 1 for 1, replacement for the old one (essentially the crux of this discussion). there is often some scenario/use-case not catered for in the new feature/method. This is where the software company has to make a hard decision and sometimes simply say 'we are no longer going to support that scenario in a direct like for like replacement. You are going to have to make some other changes to adopt the new feature to continue to achieve the same outcome in the future'.
And that is a bitter pill to swallow for customers impacted.
And they often demand to speak to people 'in charge' to put their case forward for why something should be done differently.
And the software company might even organise calls with Program Managers in charge of these decisions, or even regional Vice Presidents. Heck, if you spend enough money with the company, you may even get the CEO.
But it never (in my experience) changed the outcome. Everyone listens, everyone empathetically understands the customer's position. On the odd occassion, I've seen deprecation dates extended to give customer's more time, but the clock is still ticking and the outcome is unchanged; just delayed.
And don't get me wrong, the people that work in these companies are all (generally) great people and do care about customers. However, people that rarely interact with customers get to make these 'hard' decisions (as they aren't in the line of fire for the most part) and from a software development architecture, lifecycle, maintenance, security, etc. perspective they are usually sound decisions.
Anyway, that's just my experience that might help explain some of the behaviours of these large companies.