This is true. But SymPy is a library for symbolic mathematics, rather than arbitrary precision arithmetic. This, together with some number-theoretical functions come with backends like the gmpy2. As a fallback — Python builtin int’s and stdlib’s functions (and Fraction class) could be used.
So, SymPy will rather benefit if the stdlib will have more such functions. In past, SymPy had own implementations for isqrt(), lcm() and even gcd(). Looks like reinventing the wheel.
Same for the mpmath: it has a small private mpmath.libmp.libintmath module mostly wrapping the gmpy2 functions and provide missing (on the CPython side) batteries, if the gmpy2 isn’t used.
I don’t think there are problems wrt maintenance with current content of math-related modules. Of course, maintenance cost might be an argument against new functions. But it’s so regardless from the module split.
Well, sometimes on complex numbers too (prod/sumprod almost useless in such cases, but they can consume such input). But sometimes they can’t be called on real numbers:
>>> math.factorial(3.14)
Traceback (most recent call last):
File "<python-input-2>", line 1, in <module>
math.factorial(3.14)
~~~~~~~~~~~~~~^^^^^
TypeError: 'float' object cannot be interpreted as an integer