Four year old question, but while there are some good answers already, I'll throw another few points into the discussion:
GCM has an effective length limit for any given key + nonce pair, after which its security degrades drastically. From Wikipedia:
For any given key and initialization vector combination, GCM is limited to encrypting 239−256 bits of plain text (64 GiB).
Thus, if you're going to use GCM for large data blobs or long-running or high-traffic connections, you need to have provisions to re-initialize before this limit is hit, on both encryption and decryption. That complicates your message format or introduces an artificial length limit. In fact, even if you don't expect to run into this issue, you need to have a check in place; code that today never handles more than 4GB at a time might in future handle 100GB messages and break your security assumptions.
GCM is more fragile against bit-flipping attacks. If for some reason you don't verify the message integrity (e.g. because you tried to decrypt only part of the message, or because you are using OpenSSL and forgot to supply the authentication tag so the API just acted like normal CTR mode), an attacker can have flipped arbitrary bits in the ciphertext with the effect of precisely flipping those bits - and only those bits - in the plaintext. With CBC, flipping one or more bits in ciphertext block N will flip exactly those bits in plaintext block N+1 (and nothing else in N+1 or any subsequent block), but it will also completely scramble the plaintext of block N. Thus, bit-flipping attacks in CBC require tolerating corrupting the block proceeding the target block, or that the target block is the first block (in which case you flip the bit[s] in the IV, which works fine). This isn't a huge difference - in either case, you really need to check the message integrity, and of course GCM does that for you (if used correctly) while CBC requires having some other method (such as an HMAC) - but I have actually seen code that was "using GCM" (with OpenSSL and under the mistaken assumption that the OpenSSL API isn't an entire battleship worth of foot-cannons) but vulnerable to catastrophic bit-flipping attacks where CBC wouldn't have been at such risk (the data being tampered was JSON and the corrupted blocks would likely have been invalid to the JSON parser, preventing use of the tampered data).
GCM reveals exactly the length of the plaintext, unless you add padding prior to encryption. This is because block ciphers in counter-based modes act like stream ciphers, where the ciphertext (not counting IVs, MACs, or similar) is exactly the same length as the plaintext. CBC only adds a small amount of length masking - any message will be padded out to a multiple of the block size, which is 16 bytes for AES - but sometimes that little bit matters (though if you think that's a likely risk for you, you should pad your data to a constant length no matter what cipher you use).
Of course, that padding is a risk factor too. Used in certain scenarios, CBC runs the risk of padding oracle attacks, such as the catastrophic POODLE attack that was the death knell for SSLv3. Unlike CBC padding validation, there's no way to use GCM authentication tag validation to determine the message contents without knowledge of the key. To be fair, there are many ways to protect against padding oracle attacks and they are only a risk at all if there is something that can act as an oracle for arbitrary modified copies of a message, but the high risk of them in CBC is one reason not to use it. Of course, that's not so much a reason to use GCM in particular; there are many cipher+mode combinations that don't have this problem.
