(I'm a windows dev type)
I would say that there are 2 issues with relying on the registry:
1) Default values (ie. set by Windows upon OS install) are broken and MS never fixes them.
2) The values can be changed at any time, by any app. Thus the values are unreliable.

If I were to code it from scratch today, I'd create a three-pronged approach:
a) Hardcode a list of known types (fast & reliable).
b) Have a default case where unknown types are pulled from the registry. Whatever value is retrieved is likely better than returning e.g. "application/octet-stream".
c) When we neither find it in hardcoded list or in the registry, return a default value (e.g. "application/octet-stream")

For what it's worth, my workaround will be to have my app delete the 
HKCR\MIME\Database\Content Type\image/x-png regkey, thus forcing the original braindead mimetypes.py code to use HKCR\MIME\Database\Content Type\image/png

And, for what it's worth, my patch is actually faster than the current mimetypes.py code because I'm not doing reverse lookups. Thus any argument about a difference in speed is moot. Arguments about the speed of pulling mimetypes from registry are valid.

Another registry based approach would be to build a dictionary of mimetypes on demand. In this scenario, at startup, the dictionary would be empty. When python needs the mimetype for ".png", on the 1st request  it would cause a "slow" registry lookup for only that type but on all subsequent requests for the type it would use the "fast" value from the dictionary.
Given that an app will probably use only a handful of mimetypes but will use that same handful over and over, such a solution would have the benefits of (a) not using hardcoded values (thus no ongoing maintenance), (b) performing slow stuff only on demand, (c) optimizing repeat calls, and (d) consuming zero startup time.

I'll code his up & run some timing tests if anyone thinks it's worthwhile.

BTW, who makes the final determination as to if/when any such changes would be incorporated?