Afaik, as long as a weak cipher is enabled on both client and server, a MITM attacker can force it to be used. It involves manipulating the handshake to tell both parties the other one doesn't support any better cipher.

Eh, no. Maybe in SSLv2, but the first thing TLS encrypts is a hash of the entire handshake. Modifying the cipher list would change those hashes into something different.

Unless you have a client which will happily disable a cipher and try again when encountering an error. But if you do that, you don't deserve any security.

Do you want to make the gamble that every server has "honor cipher order" on and configured in a saner way?

Yes, you might have a point, depending on the application - but I guess most apps do have their own set of "backend servers", so modifying the servers or the client should be pretty much the same effort. Modifying the server doesnt need a client side update, though.

Weak cyphers should be disabled on the server entirely, not just re-ordered.

Knee-jerk disabling of RC4 because it's "weak" would almost certainly reduce the security of the Internet, because you can't simply evaluate TLS ciphersuites based on the strength of their core cipher; there are lots of deployed TLS clients that can't do block cipher crypto securely right now.

Examples please?

RC4 was first used as a mitigation for the BEAST blockwise-adaptive attack on CBC-with-chained-IVs from SSL 3.0 and TLS 1.0, and then again as a mitigation for the "Lucky 13" timing-based CBC padding oracle that remains a problem in TLS 1.2 when block ciphersuites are used.

Ok, thank you. I misread - I thought you meant that there were clients which weren't capable of handling block cipher suites (e.g. for performance reasons). You made me look into "Lucky 13" though, so at least I learned something!