First things first: don't panic. Don't do anything rash, and take time to think.
The slides which have appeared today describe new results on bias in RC4. RC4 generates a key-dependent stream of pseudo-random bytes, which is then XORed with the data to encrypt (decryption is identical). It was known that the output of RC4 was slightly biased, i.e. some byte values were more probable than others, especially in the first bytes of output. This leads to the possible following attack: assuming that a given secret message m is repeatedly encrypted, each time with a different key but always at the same position in the stream, then observing the encrypted data would allow to recover the message m. Indeed, if at position j key stream byte x is more probable than all other 255 values, and the attacker observes that encrypted byte value b happens more often, then he will guess that x = b XOR p for plaintext byte p, thus p = x XOR b.
It was usually assumed that though RC4 has biases of that kind, they were not really vulnerable in the practical usage of RC4 in, say, SSL/TLS.
The new results add a few more biases to those which were known, and in a more systematic way, and and gives measures. The measures partially confirm the stance above. Of course, the slides are prone to take an apocalyptic stance and to warn of utter breakage, because: 1. researchers need to do a bit of marketing and advertisement on their results, so as to attract funding, and 2. it is the Bernsteinesque style to shout that the End of Times is nigh, and that everybody else is wrong.
What the figures say is that it takes a few millions of connections for the attack to work. In a practical SSL/TLS setting, where the target is a cookie value, you won't open a new connection more than once every 15 seconds or so, because the browser and the server will "keep the connection alive", so it would take one year of 24/7 Web surfing, always on the same site, always immediately after the browser or the server decided to close the current connection, to become susceptible to this attack. Therefore, don't panic. There is no reason to rush and delve into cipher suite settings. Yet.
RC4 should still be phased out in due course. Indeed, the biases are slight, but bigger than previously expected ("we" thought that the "few millions" were "1 billion or so"). The safety margin is becoming quite thin. RC4 got a revival lately due to the BEAST attack, but it was already considered as a temporary measure. Indeed, the BEAST attack no longer works because workarounds were found.
One way to "fix" RC4, which has been suggested many times, is to drop the first 256 (or 512 or 1536 or whatever) bytes of output, since these are the most biased of them (the graphics in the slides show that quite clearly). But this would not be compatible with RC4-as-we-know-it, so it would make little sense to force that on SSL/TLS. If SSL libraries must be modified to implement a better algorithm, they may as well use one which is already standardized, i.e. GCM (see RFC 5288 for the integration of GCM into SSL/TLS). This would be better than a refurbished RC4 which would still has other biases (slighter, but still detectable, and not limited to the first bytes of output).
For now, do nothing. But see what Google will do. What Google does, the World will follow.
On an immediate basis, if you are really that worried, switch back to AES/CBC (or even 3DES/CBC), despite BEAST which, as explained above, does not work anymore with an up-to-date browser (and if the browser is not up-to-date, then the user has much more pressing issues to fix !).
In an ideal world, this new attack, despite its lack of immediate applicability, will prompt vendors to implement TLS 1.2 + GCM, and the Web will be safer.
