As others have mentioned Go and rust are nearly old enough to drink.

And the answer is pretty simple, if an existing language does something differently to how a group of people wants to work, someone will eventually write a language to do it that way.

There’s no single way to solve a problem, and that’s a good thing. If someone wants to whip something up quickly there’s a host of high level languages to do that in, it just probably won’t be especially quick. If you really care about performance, there are low level languages with varying levels of safety measures. Then there’s the whole code style thing, you might be a functional programming monk who is truly at home in APL, others may still long for something a bit more LISPy.

stuff that used to work fine in whatever old language it was in is now rewritten in a new language.

This is an illusion. If a project is moving from one language to another, that’s not a lightly taken decision, and almost definitely means they’ve had it with all the issues brought by the first language. I’m assuming you’re referring to the movement from C/C++ code to Rust that I’ve seen a fair bit.

This one particularly is because in C-like languages, any engineer will make mistakes, and those mistakes may never be obvious enough to be fixed. These kinds of mistakes are what cause those random crashes that never get fixed, but more severely, they often also give an opening for a security researcher (or someone more nefarious) to exploit. No one typically wants their software to be used for making people’s lives worse, so a lot of effort will be put into trying to catch those issues early, and manage the situation when one isn’t. With the advent of AI many projects have seen an exponential increase in the number of security issues they’re dealing with.

Or, they could bite the bullet and move to something like rust which keeps the performance benefits, but removes the ability to even make the mistakes in the first place.