Your phrasing suggests that this trend is wasteful and will not result in a net improvement in software security overall. The numbers suggest otherwise. Memory corruption exploits currently occur twice as often as all other classes of exploits combined, and disproportionately account for the most severe exploits in the relevant studies. Automating them out of existence means being able to spend more time and attention on everything else.

I'm not so sure. If developers and testers and QA teams can spend less time on a class of issues, I imagine they'll have more time to spend on the other classes of issues, lowering their exploitability as well.

That's not a great take in practice. The main example in the article is Rust and while they concentrate on the memory safety, modern languages which provide it also provide other great features. If we stick with Rust, we also get fewer concurrency issues (language enforced), logic issues (algebraic data types help), encoding issues (richer APIs help), etc.

Try to find a specific vulnerability class which actually has a chance of getting more likely if you move from C to Rust.

... which is still a net win given that logic errors, AFAIK, take more effort to locate and exploit. (If someone has hard data that prove or disprove this, please share.)