This is complicated by that slamming unrelated functions into a single module makes careful docs more verbose and/or hard to follow. For example, the current math module docs still say:
Except when explicitly noted otherwise, all return values are floats.
Which used to be true, but which has become nonsense. None of comb. factorial, gcd, isqrt, lcm, perm, floor, or ceil returns a float, but the docs don’t say so. In a hypothetical imath, where they belong, a similar catch-all:
Except when explicitly noted otherwise, all return values are ints.
could tell the truth just once. Shared context is … shared. Cuts the verbosity of the docs and reduces the conceptual load. As is, we’ve settled for docs that stopped being truthful years ago.
Splitting functions into related groups also aids discoverability. For example, I don’t believe anyone has ever suggested pushing the statistics module functions into math, and such a thing was never considered to begin with, despite that those too are “just math”. If you’re working with statistics, that’s the module you work with, and your IDE will suggest helpful completions when you ask it what starts with statistics.xyz...
Same thing for any module with focus. When I’m, .e.g., working on a problem in combinatorics, I have 0 interest in seeing an IDE suggesting any float functions. I’m working with ints then, and anything having to do with floats is pure noise for the duration.
Similarly, if I’m working with trig functions then anything having to do with ints is pure noise for the duration. I actively, e.g., do not want to see comb come up when what I want is cos.
Little things like that matter too. They add up 
.