AEAD cipher implementations are generally encrypt-then-authenticate internally (while the CBC ciphers in OpenSSL were not). TLS really was in need to get rid of the authenticate-then-encrypt which required special handling of the CBC code for block ciphers such as AES. The AEAD ciphers - regardless of the internal structure - should be immune to the problems caused by authenticate-then-encrypt.
AEAD algorithms generally come with a security proof. These security proofs are of course dependent on the underlying primitives, but it gives more confidence in the full scheme none-the-less.
These ciphers are often single pass (OCB, not often used), 1.5 pass (GCM, Poly1305) or 2 pass (EAX). That means that they generally have an execution speed advantage over two pass schemes using CBC + (H)MAC. Even a scheme as EAX can have performance advantages if a higher level language (Java, Python etc.) is used to implement TLS. This is because it is easier to create a fully optimized implementation for one algorithm (EAX) than for a combination of two algorithms at protocol level (CBC + HMAC). Internally EAX is simply CTR + CMAC.
Furthermore AEAD schemes generally can be (forced to) adhere to RFC 5116. That means that there is only one interface required for all of the AEAD ciphers with regards to the handling of the IV and plaintext. It is of course possible to let CBC + HMAC adhere to this RFC as well though.
Speed and security is probably the reason for Google to already support ChaCha20 + Poly1305/AES in Chrome. With such a big elephant in the room it is kind of hard to ignore this scheme by Daniel J. Bernstein (et all). It's a 1.5 pass AEAD cipher that uses a fast stream cipher underneath, so it's pretty efficient overall.