That’s already happening.
First, this will of course not immediately delete all legacy vimscript from the Neovim repo, so things will continue working just fine. All it means is that including future changes will become a bit harder as we can’t simply plonk the updated files into our tree.
However, the differences are usually fairly superficial so it’s not that hard to make analogous changes manually in our runtime files, even though it’s more work. (In fact, we’ve already been doing that quite a while for some more complex vimscript files that depend on editor features, most notably termdebug.vim.)
In the medium term, any file that is converted to vim9script is license for us to just rewrite in Lua (and possibly making bigger improvements to the design) – like the recent filetype.lua. I would expect more of this; possibly using a transpiler like vim9jit in case there’s a huge surprise batch of vim9script conversion when Vim9 is released.
(And regarding your last comment: as long as the runtime files remain legacy vimscript – which may be for a while, since these are often written by external maintainers who may deliberately keep them in vimscript as a lingua franca that serves both Vim and Neovim communities – the contract “runtime file improvements go through Vim” of course remains.)
Long term, we would hope that tree-sitter support becomes expansive and stable enough to completely replace the old regex-based runtime. But that is a long way off…