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.