I agree with you that according to RFC1428, use of unknown-8bit is implicitly recommended.  However, note that the RFC itself is not standards-track.  I agree with your interpretation that in this context the email module should be considered a gateway.  I think it is certainly best to convert to MIME words, as you say.

However, if there isn't already, maybe there should be an option to bounce such headers back to the user?  That is, in an interactive application this should be an error.  Of course we should help the user by allowing and documenting (perhaps even defaulting to) whatever we choose for the unknown encoding.

I don't recall ever seeing unknown-8bit in the wild.  What I do see in the wild a lot, and specifically in Mailman moderation traffic, is simply "unknown".

A quick google for "unknown-8bit" pulled up some old (2002) discussion of unknown-8bit causing problems for some MTAs.  I didn't follow up to see what those were.

I don't have time to do it myself today (but would be willing to help out if you can wait up to two weeks -- I have travel coming up), but I suggest checking for IANA registration of "unknown" and "unknown-8bit".