This is almost all down to pragmatics for me.

For sum() and prod(), if there are only two operands then there are trivial other ways to spell that (+ and *).  So it makes most sense for them to accept iterables instead.  Essentially, e.g., nobody would ever _want_ to write sum(2, 3) instead of 2+3.

max() and min() differ in that there is no other simple way to write the 2-argument forms.  max(x, y) _is_ commonly wanted - but so is max(iterable).  It's a weird function signature, but nearly always does what's intended.

gcd() (and lcm()!) differ from both in that they're nearly always wanted with 2 arguments.  "0, 1, or >= 3 arguments" are possibilities, but rarely wanted.  It would be a PITA to need to write, e.g., gcd((x, y)) instead of gcd(x, y) for the overwhelmingly most common 2-argument case.  So they should be *args functions - provided we want to cater directly to "0, 1, or >= 3 arguments" at all.  Fine by me if we don't.  I'm only +0 on generalizing beyond "exactly 2 arguments".

For the rest, I agree with Mark.  In particular, gcd() must be 0.

Serhiy, a "bulk" gcd can be more efficient than nested function calls by exploiting a common case:  it can get out early when the gcd-so-far becomes 1 (since gcd(1, anything) == 1, it doesn't matter what the remaining arguments are).  For "random" integers, it's already the case that gcd(i, j) == 1 over 60% of the time.