> I am not sure that a simple one-line function is worth it.

FWIW, it is often the one liners that turn out to be the most useful building blocks.  In this case the one-liner is inconvenient (two imports), not as fast we would like, and a little opaque:  functools.reduce(operator.mul, iterable, 1).

> PR 11359 looks too complicated.

I would be happy with the simplest possible implementation.  That said, we do have a history of going gonzo in C internals to get better speed/space performance (look the code for math.factorial() for example), to have better accuracy and avoid overflow/underflow (math.hypot() for example), or to implement particular NaN/Inf handling not present in a naive implementation.