How is padding oracle attack mitigated by encrypt-then-MAC?
The biggest issue with padding oracle attacks are when the padding is not very carefully implemented (for example if using EtM you must calculate the MAC over everything - including the padding). To pre-empt references to the classic Belare-Namprempre paper, be wary - their results do not apply to modern primitives, since nowadays we prove security differently. See instead the relevant Namprempre-Rogaway-Shrimpton paper from Eurocrypt 2014 (discussed here).

Padding oracle attacks are (supposed) to be mitigated by only presenting a single error. This is pretty well standard now (in that a sensible scheme will just say 'invalid' rather than 'padding wrong' etc), but timing errors exist that allow you to differentiate padding errors from other errors.

The idea is the in Encrypt-then-HMAC, you are always calculating the MAC over the entire message. So, let Bob receive a message, which he will parse as $(C||T)$. He will calculate $HMAC(C)=^?=T$. He can do this without caring how $C$ was put together, and as such calculating/checking the MAC won't leak any information about what's within $C$.

Conversely, suppose we have MtE. Then he receives $C$, for which he believes $C=E(M||T)$, with $T=HMAC(M)$. Having decrypted $C$ to get $M′||T′$, he now has to work out how to calculate a MAC over $M′$. This is where the padding oracle occurs, because the decryption algorithm has to work out how much padding there should be, leaking information about the message.