TL;DR: GCM has been shown to be secure, which is not the case for encrypt-then-HMAC.
There are a few things to distinguish here. First is the difference between asymmetric and symmetric cryptography. If messages are encrypted with the public key of the recipient and signed with the private key of the sender then there is a clear difference in key usage. Obviously the private keys when sending messages are kept by different parties. Now these parties could use the same key for decrypting and signing, but these keys may well have different life times. For instance, it may be that you want to decrypt messages in the far future, meaning that you need to keep the private decryption key. However, generally you don't need to keep the signing key; you can still verify messages with just the public key and replace the signing key with the new key.
However, with an authenticated cipher such as GCM we're commonly dealing with session keys. The session keys for confidentiality and integrity protection / message authentication are commonly generated at the same time. So there is no need to have separate life times or access conditions for them.
Another reason to use separate keys are algorithmic vulnerabilities. Cryptographic algorithms will always be designed to keep the key secure. However, the algorithmic proofs (or at least indications of security) generally do not consider usage of the key in other algorithms. Imagine you have a set of equations trying to show security. Now mix those equations with a whole new set of equations from another algorithm that uses the same variables, and try to show that security holds. This is generally impossible, meaning that any security reduction is likely void.
In the worst case the encryption algorithm and MAC use similar constructions. In that case it might well be that the resulting set of equations is actually insecure. A good example of this is a block cipher mode in CBC mode that uses CBC-MAC. It is easy to prove that this scheme can be insecure when used with the same key.
HMAC is a completely different scheme than any block cipher mode of operation. That makes it very improbable that re-using the key for authentication will lead to vulnerabilities. However, it will also be next to impossible to prove that there aren't any, so it is therefore still not recommended to reuse the encryption key for authentication with HMAC.
A slightly less serious issue is that keys may not be usable for different algorithms. For instance, a HMAC-SHA512 (SHA-512 is often faster than SHA-256) key cannot directly be used for AES encryption, as the maximum key size of AES is 256 bits. For software this may not be a huge issue, but generally keys are generated for a specific algorithm. This is especially an issue on hardware modules, where the key data can often not be retrieved. It would be impossible to use a HMAC key as an AES key.
So it may be easier to have one input secret that can be fed into a key derivation mechanism such as HKDF. This mechanism can then be used to derive the encryption and authentication key. This is an easy way to split one secret key into two secret keys. Obviously this option is not available in the setting that requires asymmetric cryptography.
For AES-GCM the key is only used in AES-CTR mode. This mode is both used for protecting the GMAC value (with a specific counter value) as well as keeping the message confidential. This construction is shown to be secure in a paper that is unfortunately payware. This proof has been studied by other cryptographers and shown to be valid. There have certainly have been results that have shown weaknesses in the GCM construction with regard to construction of the authentication tag and derived authentication key, but the overall security claims have withstood the issues - after some tweaking.
So unless further holes in the security claims will be found, AES-GCM should be secure even though it just requires one key.
For the scholar, here is the security claim in the original paper:
GCMis secure in the concrete security models introduced by Bellare, Killian, and Rogaway [20] for
message authentication, and Bellare, Desai, Jokipii, and Rogaway for confidentiality [22], against
adversaries that can adaptively choose the plaintext, the additional associated data, and the IV
(as long as the requirements on these inputs are respected). Its security relies on the fact that
the underlying block cipher cannot be distinguished from a random permutation, an assumption
which is common in cryptographic designs and which appears to be valid for the AES.
And here is a link to a freely available draft that is likely the source for the linked-to payware paper in the previous section: Flexible and Efficient Message Authentication in Hardware and Software
