The overwhelming majority of bugs of any sort live in new code. The longer a piece of code has been around, the safer it generally is (with occasional high-profile exceptions). This means two things:

1) The most cost-effective way to eliminate the majority of memory bugs is to just start writing all new code in a memory-safe language. If you were going to write new code anyway, you may as well do it safely.

2) Going back and re-writing existing code that doesn't need to be changed may solve latent memory bugs, but it will likely introduce other regressions that could be worse for security or for user experience. If code doesn't need to change, it's often better to leave it as is.

Not that a rewrite is never called for, but it's not necessarily the best course of action by any metric (even when neglecting the cost).

Part of that safety is users working around known bugs, leading to inefficient solutions to whatever the code is supposed to do.

People tend to forget that they don't have to live with those problems, but they still have a cost

New code includes rewrites, like the Bluetooth stack.

Mostly new code. They've rewritten some core, high-importance pieces. But any mature OS is a massive codebase, so it just wouldn't be feasible to systematically rewrite the entire thing indiscriminately