I've seen all over the place, it's pathetic.
Great code is great code, doesn't matter who it comes from and who gets the recognition. Think about the project over yourself.
Code from an outside developer will just be committed and never touched again in many cases, since the outside developer doesn't intend to stay and work on the project. If you don't believe me, look at the history of the ffmpeg project: there are enormous swaths of unmaintained code (and uncommitted code) for exactly this reason.
Thus, it is often reasonable to have higher code standards for code whose author does not intend to maintain it into the future.
These things are relative
The point was sometimes stuff just works, much better than a mess of a refactored project that has a core flaw.
Just because it's not currently maintained does not mean it won't be maintained in the future.
(I think your misunderstanding: I was replying to the generalisation with a generalisation)
Programmer A has been working with me for a long time, has done a lot of B- to B+ code. I trust that what he does is going to be up to that level.
Programmer B has been working with me for a long time and consistently turns in C level code. It isnt great, it isnt horrid. Call him pedestrian. When I get something from him, I know what it is going to be. Adequate. Not everything has to be great, most things move forward on adequate because there are too many things to get for B and A level people to do them all.
Programmer C is someone I don't know it all. Maybe I've heard of them by reputation, maybe not. Doesn't much matter, there is no trust there, I don't know what I'm getting. If I'm responsible, I'm going to vet their code closely. Make sure they follow coding conventions, best practices, etc. This takes time on my part. And my time is limited because now I am BDFL or some similarly ridiculous title that means "He's a busy guy".