I (along with some other admins) run a mailman3 (3.2.1, on debian stable) mailing list for notmuch (https://notmuchmail.org). It's our main method of reviewing, so we get lots of mail from git-send-email. Occasionaly people send it with Content-Transfer-Encoding 8bit. As far as I can tell what happens then is mailman3 re-encodes it as base64, taking the line endings as CRLF. git-am is unable to apply the patches that have been re-encoded.
This seems somewhat related to 1. Like one commentator there, I would be happy to be able to turn off the re-encoding, although I have the feeling from playing with the python email libraries that this might not be that easy. I'm writing in hope that someone can suggest another workaround, perhaps some kind line-ending rewriting before base64 encoding. I guess with 8bit transfer encoding there probably isn't a clear distinction between the line-endings on the wire, and the intended line-endings for delivery, but it could be inferred from the "X-Mailer: git-send-email" header.
As a test, I sent the same patch through our mailman instance with Content-Transfer-Encoding base64 and that applies fine, since the original \n line endings are inside the base64 container. It's a known mis-feature of git-am that it can handle either CRLF line endings or base64 encoding, but not the combination of both. I have a local workaround involving re-formatting the patches, but I'd really like anyone to be able to apply the patches from the list archive.