When can I consider a ciphersuite an Authenticated Encryption?
If properly implemented, all TLS ciphersuites provide authenticated encryption. The caveat here is that
- The implementation actually must return $\perp$ (math-jargon for "error") if the decryption was unsuccessful, it must not tell anybody why exactly $\perp$ was returned.
- The time it takes for an implementation to return $\perp$ must not depend on any secret values (such as the key contents or the message contents).
If implementations (eg BearSSL) achieve these two constraints, then yes, the ciphersuites provide authenticated encryption (in the technical cryptographical sense).
However, some people (eg Google) don't consider the the CBC-based suites authenticated encryption, because they use a generic construction specified by the TLS protocol. In such a context, only ciphersuites that use an atomic primitive providing authenticated encryption (atomic meaning indivisible from the point of view of the TLS protocol) counts. As TLS really uses the CBC modes to do HMAC-then-CBC they don't count, as opposed to the modes like GCM, CCM, EAX or ChaCha-Poly1305 which have specialized security reductions and can / should not be split up from the point of view of TLS.
Is AES-CBC in TLS 1.2 an Authenticated Encryption
Do padding attacks in AES-CBC render it considered non-Authenticated
No, attacks do not change whether a (theoretical) construction satisfies a security definition. The thing is with the theoretical security definitions: They are based on a security model and if the real world isn't reflected by this security model, then a cipher may satisfy the model, but fail in the real world. What does this mean? Timing information (as exploited by Lucky13) is not part of the (formal) security model for authenticated encryption. On the other hand, a construction that has more than one error message is not authenticated encryption scheme, because these may only have one (generic) error message.