There's several different reasons why these changes are beneficial.  It'll help make the modules more compatible with PEP 554 in the future, enable more code re-use across Python VMs, reduce code maintenance going forward, and may also help with performance oriented changes in the future.  

On the PEP 554 front it is necessary to remove the static state that is used in the modules as we can't have sharing across the interpreters.  The modules that are loaded into the different interpreter will need to not share any state on so all of their state needs to be per-instance state (there's also just an argument that static global state is just kind of ugly).

On the re-use across VMs front it'll mean that alternative VMs will only need to stick to the stable API and well be able to use these modules as-is without having to re-implement them.  It may not even be strictly necessary that these modules stick to 100% of the stable API if the places where they go outside dramatically help the implementation (for example PR 15805 uses _PyBytesWriter still).  

Sticking to the stable API will also naturally make it somewhat easier to make changes that impact the non-stable API.  By it's very nature the stable API is going to change less (theoretically never) and therefore these modules will be less impacted by updates which are attempting to improve performance on the core.  One example of that is the recent vector call support where many of the types needed to be updated (although trivially).  

So the final, and probably most speculative area, is the possibility of unlocking performance in the core runtime per Victor's stable API work: https://pythoncapi.readthedocs.io/.  By having less dependencies on the core implementation details it should be easier to evolve those going forward an making it easier to unlock future performance gains in the core.