Since "basic software engineering principles" have been invoked, I'd like to point out that many of the standard motivations to modularization don't apply in this case. So it is fair to ask what *specific* benefits such a restructuring may have. Such a description is necessary in advance in order to determine whether a specific restructuring actually achieves the stated objectives.

In the Wikipedia article on "Modular programming", the main advantage (as in "top-down  design") is that you can decompose a yet-to-be-built system upfront, and split the work into several teams, which then can develop the system independently, and only need to integrate at the end. This is less relevant as the system in question is already built.

Another motivation given in Wikipedia is reuse in different systems. There isn't really any reuse planned for the code in question, but perhaps reuse in other Python implementations would make a point. If that is the motivation, the split should be to separate CPython support code from other support code.

The wikipedia article also claims that the code is easier to debug, update, and modify. Easier modification may come from the notion of abstract interfaces: the module implementation can be changed without affecting module use (if the interfaces are unchanged. For this case, the code is already at a module boundary (of the support module); I fail to see why further modularization would improve anything.

Easier debugging may come from less code being involved in a certain code path. Mere refactoring cannot improve that. You have to rewrite the functions, but that would be possible even without splitting the module.