I still think complicating the API isn't worth it.  Of late, we've gotten in the habit of a complexity to even the simplest of things.

In the case of sequences, we already have a reasonable solution:

    low = min(seq) if seq else default

In the rarer case of non-sequence iterables, catching a Value error is the traditional solution -- not pretty, but not difficult either.

In the past, Guido has rejected that notion of "add a default value to every function than can raise an exception".  For example, someone wanted to add a get() method to lists so they could avoid catching an IndexError, something like s.get(index, default).  IIRC, his motivation was that "avoiding API clutter" was more important than supporting an uncommon use case that already had viable solutions using plain Python.

My own principle is that it is okay to add an initial extra feature to function, but not multiple extra features.  This becomes more important when the function already has API issues.

The min() / max() functions started-out with an API problem because of their dual signature:  min(s)  versus  min(a, b, c).   That creates an ambiguity in that case of min(*t) where the result depends on the length of the input.   IMO, that issue would be exacerbated by the addition of a default argument (i.e. it would tend to hide the error from test cases):

    for t in [(10, 20, 30), (10, 20), (10,), ()]:
        print min(*t, default=100)

Also, I don't think we should forget the lessons learned about adding unnecessary arguments to functions.  For example, we let someone add start and end arguments to str.startswith() and str.endswith() because "it seemed more parallel with str.find()" and because "someone wanted it once a piece of code somewhere".  The downside only became apparent later when there was a legitimate real use case for another feature request:  searching multiple prefixes and suffixes.  Because we had wasted the positional arguments, we ended-up with the awkward str.startswith(str-or-tuple [,start [,end]]) signature.   That is why we have to write, filename.endswith(('.py', '.pyc')).  The double parens are part of the cost of API bloat.

Lastly, when it comes to common-place functions like min() and max(), we can assess needs easily by looking at what other languages have done.  Looking at Excel, SQL, Java, Haskell, C# etc, I don't see a precedent for this feature request.

Grepping for min/max in my own code and third-party libraries, I don't see any cases where the code had a need for this feature.  If the need arises, it certainly doesn't come of very often.

If you guys all think this is an good feature request, then by all means, go ahead and add it.  My recommendation is to show design restraint and refuse the temptation to grow this already awkward API when you don't have to.