Short: CBC mode in context of TLS protocol has had security issues, and would have had to be reworked.
AES-CBC mode combined with decent HMAC can be as secure as AES-GCM. However, combining the cipher and MAC securely has been in practice found to be much easier said than done. Also, padding that is required by AES-CBC mode complicates things.
In particular, within the history of the SSL and TLS protocols, there is a long history of security vulnerabilities resulting from misuse of CBC mode or within combination of CBC and MAC, such as BEAST and Lucky13.
After the Lucky13 attack (a timing oracle caused by MAC-then-encrypt), it was thought that TLS should change ordering of the operations. Changing order of the operations would have affected the backwards compatibility with previous implementations so it was after all thought that it is more practical to switch to authenticated encryption only.
In addition to security aspects, there are some other practical benefits of AES-GCM over AES-CBC and HMAC:
- On most platforms with hardware acceleration or AES-NI instructions, AES-GCM is many times faster than AES-CBC with HMAC. This is because AES-GCM is designed to be more parallelizable.
- Generation of random bits is relatively slow. This is also where AES-GCM excels. Random bits are more seldomly needed than with AES-CBC (in TLS 1.1+.)
- AES-GCM in average does not extend the size of the message as much as equivalent combination of AES-CBC, HMAC and padding.