In the below TSL1.2 cipher list, why should one explicitly disable RC4 instead of just removing it from the list of ciphers.
ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!RC4
What problems does it cause? Anything that I should be careful about with respect to client/server SSL communication?
Yes you don't need !RC4 or even -RC4 because none of your terms ever adds any RC4 ciphersuites.
To be on the safe side, you might add -aNULL or !aNULL because your terms do add many anonymous suites. In practice many probably most or all of the systems you connect to won't negotiate any anonymous suite anyway, but it's best to make sure they can't.
I assume by SSL you actually mean the TLS protocol(s), preferably at least version 1.1. Because TLS (through 1.2 at least) is based on and very similar to SSL3 much software and documentation continues to use the old name, but you should be certain you never use the actual SSL3 protocol which is now badly broken by POODLE, and should try to avoid TLS1.0 which has the exposed-IV flaw that was exploited by BEAST although most stacks now adequately mitigate BEAST using 1/n (or sometimes 0/n) record splitting. And the GCM ciphersuites you prefer (by putting them first) only work in TLS1.2 (or 1.3 if and when it gets finalized and implemented).
Other more general considerations:
if you are the server, possess and configure at least one type (RSA, DSA, ECDSA) of privatekey that is sufficiently strong, generated properly, and protected from unauthorized disclosure, and a matching certificate chain from a CA the client(s) will trust, using sufficiently strong signatures (currently sha256 or better with RSA-2048 DSA-2048 ECC-224 or better), and for most application protocols (like HTTPS) containing the correct hostname(s). Since RSA is the algorithm most commonly certifiable by widely trusted CAs, the only one that can cover all the keyexchange terms you have gone to the trouble of adding, and the only one covered by the instructions copied to billions of websites by people who don't understand them and therefore can't improve them, you probably want RSA.
if you are the client, verify the server cert chain against trustworthy CAs and when applicable the hostname. Note that OpenSSL always (unless overridden) does the standard crypto (signature) and syntax (BC KU EKU policy etc) verification to a supplied truststore (roots or optionally anchors), but client through 1.0.2 doesn't check the hostname for you, and 1.1.0 only does if you explicitly configure it. OpenSSL does not check CRLs by default and does not fetch them, doesn't fetch OCSP, and AFAICS doesn't even check stapled OCSP yet, so you should add at least some of these, but I don't think many developers do.
In the rare case client authentication aka client cert[ificate] is used, mirror the above: client that wishes or agrees to authenticate must possess and use suitable privatekey and certificate chain, and server must verify it but usually not hostname and definitely not using stapling.
if you are the server, configure sufficiently strong and properly generated DHE (called tmp_dh) parameters -- 2048 bits is now the standard, unless you have to deal with obsolete clients (like Java 7) that can't handle it; and depending on OpenSSL version ECDHE (called tmp_ecdh) parameters -- P-256 or P-384 is usually best. 1.0.2+ can and should be set to choose ECDHE based on ClientHello 'auto'matically; below that for ECDHE, and in all versions for DHE, if you don't configure the parameters the associated ciphersuites won't be used even though you configured them as preferred.
If you are client try to verify the above, although verifying anything about DHE parameters other than raw size without generation information (which SSL/TLS does not carry in-band) is too hard. In the very rare case of 'explicit' (non-named) EC parameters for ECDHE verifying is too hard, but for named curves and especially the common ones (P-256 and P-384 blessed by former Suite B) you can rely on the (open) community having focussed attention on them.
Don't use SSL/TLS compression if you send sensitive data (like cookies) in the same record as attacker-influenced data. Many stacks never allow SSL/TLS compression, since application-level compression can usually perform better and cheaper for applications that need it, e.g. HTTP[S].
