I'm sorry, but I'm only a passing student of cryptography, and I've known that both RC4 and MD5 have been broken for quite some time now.
I don't remember the timeline, but if you're implementing code for algorithms and you decide to use the defaults "just because", you're being negligent - that is to say being pretty damn stupid.
Once again, with feeling: the fact that an algorithm is "broken" does not mean that a cryptosystem reliant on that algorithm is necessarily broken. In this particular case, the MD5 breakage is not currently relevant to TLS, and it might be decades before it ever is. And, while nobody particularly liked RC4, it was deployed to mitigate an even worse vulnerability in the MtE CBC construction in TLS.
Cryptosystems exist in strata: environments, algorithms, constructions, protocols, applications. A careful cryptosystem is designed so that a flaw in one stratum doesn't immediately destroy the entire cryptosystem. Not only did TLS largely succeed in that goal, but it succeeded in part due to the availability of RC4.
I get your point about the security of the system as a whole: my point isn't that the algorithms are on the list, just that they're at the top of the list.
RC4 may have helped TLS to succeed, but it's 2013 - surely there's something that is robust enough to be used instead by now?
Of course the simple explanation could just be for performance reasons.
No, the simple explanation is backwards compatibility. There was a client-side mitigation to the MtE vulnerability, but it broke some tiny fraction of servers in the wild so it never made it to the stable release of NSS.
