This is the answer, and correct in many ways.

If the chips are cheap and easily available, and you know their failure modes, and they've been field tested for decades, why change?

It's very different from many software development attitudes, but remember that airframe manufacturers and avionics companies employ many people just to calculate risk and failure rates. The failure rates of these things are critical to the safety of your airframe.

Would probably add that it likely has reliable real-time constraints as part of this. While I can imagine simpler ARM and RISC-V chips having similar properties, depending on the application it would likely be hard to certify any modern CPU design for a lot of medical or aerospace applications.

That mindset is inevitably going to leave you in a ditch though. Either you run out of suppliers for the chip that are willing to produce on a shitty inefficient old node under certified conditions (mostly because it inevitably gets really expensive to keep the machines for production running!), or you run out of developers able and willing to write code for these old designs where the toolchain probably is also certified and has nowhere near close to the bells and whistles of modern IDEs or the automatic benefits from modern programming languages such as pointer safety.

Anything should have a replacement budget and timeline attached.

Make you wonder how long management figured they can keep using ancient technology, just to avoid updating certifications.