Nobody likes it, but until relatively recently, the AES ciphersuites were all CBC mode, which means they burned a couple bytes of padding for every record.
RC4 is also faster than AES, which was, until very recently, an issue for server performance.
We have AES-CTR ciphersuites now, but I'm not sure how widely deployed they are.
The padding for AES cipher suites isn't a significant performance issue. The per-record IV in TLS 1.1 and later, the overhead of the tls-cbc.txt workaround for earlier versions, and/or the extra block(s) of encryption required for HMAC-SHA-2-based cipher suites are bigger performance issues.
RC4 is faster than AES on older processors. On the current generation of Intel server processors, AES is faster because of AES-NI.
AES-GCM cipher suites should be even faster yet on those processors, but they are not widely implemented. Also, I wouldn't be surprised to see more interesting papers being published about weaknesses in the GMAC function in the near future. (Note: I don't have any knowledge of upcoming papers; I am guessing there will be some based on the recent paper regarding the discovery of unexpected weak keys in GMAC.) Nonetheless, I suspect that NSS will implement them because they are part of the NSA Suite B profile for TLS and some NSS developers want a complete implementation of that.
The hash algorithm in TLS is HMAC-hash. Some uses of MD5 like secret suffix are now insecure (which is why usage of MD5 for certificate signing ended long ago), but HMAC is not one of them.
Nobody likes it, but until relatively recently, the AES ciphersuites were all CBC mode, which means they burned a couple bytes of padding for every record.
RC4 is also faster than AES, which was, until very recently, an issue for server performance.
We have AES-CTR ciphersuites now, but I'm not sure how widely deployed they are.