Don't know if I agree re RC4; BEAST is an issue with CBC, not AES.
AES-GCM should be ok, if not superior to the ancient RC4.
That said, if you know as much as you do, you don’t need that article and can fine tune yourself. It’s for people who want a compatible and secure SSL setup – which it is.
Edit: Clarified that RC4 is better than CBC as implemented, not CBC implemented with constant-time verification, i.e. RC4 will not be preferable to AES-CBC in the fixed version of OpenSSL, at least against the Lucky Thirteen attack.
We’re in the web hosting business and whenever we try to be a bit more progressive, people start yelling at us that their IE 4-using customers in rural Mongolia can’t SSL-surf their shop. When it comes to mail, IIRC some business phones were behind too.
OTOH iOS 6 support TLS 1.2, so if you’re just building a REST API for your own apps, you can go wild.
But people hold their noses and use it because browser upgrade cycles haven't shaken off a bug that happens to affect CBC mode.
As an example, see Adam Langley's comments on not fixing (i.e. making constant-time) CBC in Go: https://groups.google.com/d/msg/golang-nuts/HF5O5vAKRcQ/3cYW...
Also, blaming browsers when we've known about timing attacks against this verification for years, and OpenSSL is patching it now, is probably a bit of a stretch.
The CBC timing channel 'agl is talking about is specific to TLS's idiosyncratic mac-then-encrypt implementation. Don't ever use mac-then-encrypt. Encrypt first, then MAC.
I'm blaming browsers for (a) not implementing CTR mode (AE or otherwise) and (b) being vulnerable to the chained CBC IV vulnerability. I'm not blaming browsers for the timing attack on AES-CBC.