I am just curious as to what extent AES GCM can replace the standard CBC + HMAC option.
There are quite some advantages to GCM, for one it allows for parallel processing which makes it efficient and usable for simultaneous hardware operations. Since you compare GCM to CBC+HMAC, I will point you to the GCM GMAC extension. GMAC is the HMAC variant but is uses a Galois field instead.
A predefined Galois field, say GF(2128), can be computed independently over an polynomial, whereas CBC chains blocks based on previous results. This gives GCM a high throughput, and makes it very efficient.
Yes, there are some advantages for CBC-HMAC over GCM. Or rather, there are some disadvantages of GCM.
GCM becomes more vulnerable when the authentication tag size is smaller. GCM security breaks down completely on nonce-reuse as well, which makes it less useful for random nonces, especially when the random number generator is not as secure as you'd like it to be.
As shortly mentioned in the link there are implementation and security arguments against GCM as well.
You could always use EAX mode too, although that mode hasn't been officially standardized by NIST. EAX uses AES-CMAC for calculating authenticity, so it just relies on a fast AES to be available. It has a similar AEAD interface as GCM - it's even slightly more flexible when implemented correctly. But just like CBC + HMAC it's a full two pass protocol otherwise. And then there is OCB mode, and of course Keccak in (experimental) encryption mode.
Yes, when one or more of the systems that need to interact don't support GCM.
Older versions of .Net and Windows 2008, for example, don't and it's the same with some Java middleware stacks so if you were implementing a solution there you would have to use CBC.