Using a hot key 100 times a day for 10 years sounds like exactly the kind of thing software engineers SHOULD understand. I heard a lot of anger from Vim users when Apple messed with the escape key.
In my experience (~10 years of doing this sort of work) software engineers typically understand how their users use the software in the abstract, but not in the actual experience.
E.g. It is well understood that users rely on a hotkey "a lot." It is not understood that users are so familiar with a hotkey that, if you relocated it on the keyboard, productivity would decrease 40% for 3 months.
That distinction is fairly important when trying to decide whether {new feature X} is actually worth disrupting {old feature Y}.
UX design is done by designers and product managers. Developer just implemented ability to assign hot key X to function Y. How this ability used was not his/her concern.
Personally, I'd push back on such a change unless there was a very good reason. I feel like this violates the same kind of principle as "we do not break user space EVER". My point above is that a programmer should understand better than most how important muscle memory and shortcuts are to productivity.
I would push back too, and I think most experienced programmers understand the needs of power users[0] - problem is, they don't push back all that often. I encourage developers to try and voice their opinion about UX more often. Who knows, maybe your PM isn't a pointy-haired boss, but will turn out to be a professional willing to listen to rational arguments? I had a privilege working with such PMs; at one place, I ended up having a lot of say about UX (and provided a counterbalance to our designer) - just because I spoke up about the issues. It turned out that my views were shared by the rest of the dev team, it's just that they never bothered to voice it.
--
[0] - Almost everyone who spent most of their day job using a particular set of software tools quickly becomes a power user of these particular tools. The corollary to that is that if your software is the kind to be used at a job, it better be power user friendly, or you're going to wasting your customer's money and the life their employees.
My Experience is software engineers understand how users SHOULD use the software, which rarely matches how users DO use the software
Most of the time I experience a scenario of the engineer or support person saying "Show me what you are doing" only for the user to show some weird and non-logical (to the engineer) way of doing some task, and the engineer or support person replying "Well you should be doing it this other completely different way"
E.g. It is well understood that users rely on a hotkey "a lot." It is not understood that users are so familiar with a hotkey that, if you relocated it on the keyboard, productivity would decrease 40% for 3 months.
That distinction is fairly important when trying to decide whether {new feature X} is actually worth disrupting {old feature Y}.