Assuming you are dealing with a competent developer/team, and you are advising on adding security to their protocol. Also for the time being lets not worry about the key establishment and validating the other end aspects of the protocol.
Would you recommend AEAD, specifically AES-GCM over AES 256 + HMAC with SHA2?
I ask because there are implementation/usage caveats with AES-GCM as mentioned here.
I think you're a bit unclear about the factoring and abstraction layers here. A correctly designed AES + HMAC construction is AEAD. This is because AEAD is about what interface and contract the cryptography should expose to its callers; while the choice between GCM vs. encrypt-then-HMAC is a choice between implementations. Ideally, the code that calls an AEAD would do so through an interface that abstracts away the difference between the two implementations you propose, and the code that implements your AES + HMAC construction would expose the same caller interface as AES-GCM.
If you're looking cooking up your own AES + HMAC combination, I'd recommend you rather put some effort into finding a ready-made and well vetted third-party library. Whether it uses AES-GCM or an AES + HMAC construction isn't the most important thing. As the saying goes, don't roll your own.
You could use this internet draft that proposes AES-CBC + HMAC as AEAD cipher. It never got approved though, and with two keys, not very efficient implementation and most importantly no explicit proof of security. However, it does use encrypt-then-MAC, and includes the IV in the "ciphertext" and therefore the MAC.
GCM has usage caveats, but so has CBC-HMAC. I'd myself go for EAX mode; it only relies on AES in encrypt mode and performs AES in CTR and CMAC. It's very flexible and well structured, uses only one key. It may however not be as efficient as GCM for normal operation, and it has a relatively high overhead for small messages.