Every sizeable (and some not-so-sizeable) Python projects I've worked on have one or more 'utils' modules that collect stuff that doesn't logically fit elsewhere.  That's what test.support is for the test infrastructure.

I agree that we should not talk in generalities.  As Martin has indicated, appeal to authority in the form of "basic software engineering principles" is not enough by itself.  We should look at specific proposals and decide based on specific arguments whether they will improve matters.  And yes, their status as good engineering principles is meaningful, but only if the reasons for those specific principles actually apply in the specific case.

Certainly making the functions in script_helpers more discoverable is a laudable goal.

As an aside: I've worked on a project that is well modularized if you judge by the number and size of the source files (if you ignore a few single-class files created by former java programmers)...but it didn't follow any of the logical reasons Martin quoted for modularization: finding things in the source base was a pain, and different responsibility groups were responsible for files spread across the source tree and wound up stepping on each other's toes, and debugging was not aided by the source structure because while the APIs started out reasonably well defined they did not stay that way...because the responsibility areas were not well defined or maintained.  *Why* you modularize, and *how* you modularize, are much more important than file size.