I don't believe either the example that other mailers reject or the one that they accept are in fact RFC compliant.  Encoded words are not supposed to occur in (structured) MIME headers.  The behavior observed is a consequence of all headers, whether structured or unstructured, being treated as if they were unstructured by Header.

(There's a different problem in Python3 with this example, but I'll deal with that in a separate issue.)

What we have here is primarily a documentation bug.  The way to generate the correct (RFC compliant) header is as follows:

>>> m.add_header('Content-Disposition', 'attachment',
... filename=('iso-8859-1', '', 'Fußballer_sind_klug.ppt'))
>>> str(m)
'Content-Disposition: attachment; filename*="iso-8859-1\'\'Fu%DFballer_sind_klug.ppt"\n\n'

I will add the explanation and this example to the docs.  In addition, in 3.2 I will disallow non-ASCII parameter values unless they are specified in a three element tuple as in the example above.  That will still leave some other places where structured headers are inappropriately encoded by Header (eg: addresses with non-ASCII names), but dealing with that is a somewhat deeper problem.