Not really. I've worked as an Enterprise Architect and worked in good as well as bad architectures. If you engineer a system that backs the company into a corner of "we can never upgrade," then you're a crappy architect. Even more so if you can't hire someone to step in and maintain a project or have a drought of hardware suppliers.
>The challenge of changing the status quo once that tech has become embedded in their business processes is twice has hard.
Business process is not synonymous with "tech stack." If it becomes synonymous, you done fucked up.
>And based on my experience, the challenge of getting any new technology in a company that is mature and successful is really hard.
That's because some people do tech-for-tech's-sake. If you open the conversation with "hey, if we switch out IIS for nginx/apache, it will take 8 months, but we'll save money on maintenance and licenses, as well as spending less money on hardware," then you're in better shape than just pitching the new hotness. Of course, it's been my experience that these decisions are usually done on a whim in mature companies (hooray business!).
>There is always a benefit/cost ratio. The cost is not just development - it's training, its documentation, its lost time, etc.
Yes, of course. It's also cost of life management, staffing costs for niche/antiquated skills/getting developers willing to do long-term damage to their skills (imagine becoming an expert in coding for IE9 and lower, how do you think your resume will look in a few years?) for short-term profit.