I'd still say this is a plain bug, which simply should be fixed.

"People who have working code" must have already a smart work around: either - or! : By doing the 5 low level code lines of .as_string() on their own. (there is no other way to produce clearly either a unixfrom=True or unixfrom=False Message). 
As of now this is simply neither nor. People are just quiet (I wonder), because the bug effect is rare. 

If somebody really wants to produce a unix mbox format for antiquated purposes, he would use unixfrom=True, when calling this function. (because otherwise its not complete unixfrom). And then the patched version is ok as well.

But when you call with unixfrom=False (default), a partially unixfrom=True mangled MIME body comes out. This is just buggy ...

Most striking is, that all lines in the message body (which the mail recipient reads), which start with the word "From", are converted to ">From". This is not acceptable. 

"a little bit more likely to preserve format of the message that was fed into it" :  Certainly mail message bodies must not be altered in a funny way when mangling is not ordered. 

I cannot imagine that sb can consciously or unconsciously rely on the bug. But in 99% of cases the patch would just fix peoples buggy programs.

If this really cannot be fixed, then at least a extra function next to as_string should be added (e.g. as_unmangled_string()), which allows creation of legal unmangled message. 
The current function can so far only produce a managled message, but consistently only then if in addition it is called explicitely with unixfrom=True ;-)