I know that the RC4 cipher when used with SSL is vulnerable to certain attacks, which in the worst case scenario could result in authentication tokens being stolen. But RC4 is also recommended as a cipher to mitigate the BEAST attack.
Is it a better strategic decision, to disable RC4 and perhaps be vulnerable to BEAST, or protect against BEAST and protect against the attack RC4 is vulnerable to?
In any case, the client suggests but the server chooses. On the client side, you can specify that you prefer to use AES if possible, but if the client supports RC4 and the server wants to use RC4 if possible, then RC4 it will be. This implies that you cannot really "use RC4 as a last resort" (unless the client code does some trickery, which I don't believe mainstream SSL clients implement; namely not announcing RC4 support, unless previous connection attempts with other cipher suites have failed).
One way to look at it is that RC4-protected SSL is way better than no SSL at all. Another way is that whatever you do on the client, the server cannot be abstracted away; you are entrusting the server with your confidential data. The choice of the cipher suite is the server's responsibility, and if the server does not apply appropriate cipher suites (from your point of view) then maybe you should not send the data at all to such a careless server...
Known weaknesses of AES-CBC (the BEAST attack) don't work anymore if your client (Web browser) is up-to-date (and it really should !). Known weaknesses of RC4 don't seem to work in a Web context (because weakness exploitation requires millions of connections, and that takes time -- moreover, the first few hundred bytes of each request contain HTTP headers which are mostly uninteresting to the attacker). So it can be said that: RC4 or not RC4, that is not the question. Whether you disable or enable RC4, this is very unlikely to be the biggest security vulnerability, or even a significant vulnerability.
However, it may make sense to disable RC4, or to disable AES-CBC, in order to comply with some inflexible regulations, or to increase some (very artificial) "security mark" that some auditors seem very fond of, for reasons which have more to do with psychology than cryptography.
BEAST vulnerability has been worked out client-side, so it's no longer an issue with modern browsers.
RC4 is a weaker cipher than others since it's been shown to have a slight bias, but if used carefully and appropriately, there are no successful attacks against it.
You can't get any safer than safe; if your encryption can't be broken, then it doesn't really matter how much more it can't be broken. So in that sense, there's no compelling reason to avoid the cipher.
That said, there's no sense using a biased cipher when others are available. So going forward, you might as well prefer something else. The primary reason why RC4 is so persistent is that it's the last true stream cipher in use, making it useful for people who want to avoid thinking about block chaining. Secure block ciphers are hard enough to invent; but stream ciphers are on a whole new level, so it's not likely we'll see another.
Most likely RC4 will continue to stick around; there is no compelling direct replacement. I wouldn't prefer it, but I would expect to continue to see it.
A lot of the people recommending RC4 to prevent BEAST have recanted because of the attacks on it; the correct and forward-looking solution is updating your software to the TLS 1.1 spec.
Strategically, your options depend on your abilities. If you are allowed to dictate the user agents connecting to your service, or willing to accept that your user agent might be unable to connect to some services if that makes it more secure, require TLS 1.2 support.
There is very little that can meaningfully be done to protect users who use outdated software with known vulnerabilities. This includes people running user agents still capable of no better than SSLv3 and without support for GCM modes.
Cipher suites are negotiated in a priority order. Since some people might still be following the old advice to prefer RC4 in order to mitigate BEAST, it's likely a good choice to disable RC4, especially if your (or your users') user agents are up to date.
Given that practical attacks have been demonstrated with similar prerequisites both for BEAST and RC4, the choice is otherwise equal.
