No, MAC-then-encrypt is very, very hard to get right, because you have to avoid creating side-channels (including timing side-channels) between the decryption operation, the padding check (if you're using a block cipher mode that requires padding), and the MAC check.
More to the point, if you're fielding a new MAC-then-encrypt design, then I don't trust your crypto, because your crypto knowledge is over a decade old. Krawczyk's paper was published in 2001: https://eprint.iacr.org/2001/045
I don't know about the constructions and attack scenarios pertaining to this app, but MAC-then-encrypt is generally insecure; it's not "easier to get wrong", but is itself a flaw (typically: of exposing the cipher to malicious ciphertext, rather than screening it out with a MAC, which is designed to distinguish between valid and invalid ciphertext).
Essentially all 'misuse resistant' modes are some form of MtE, since in those modes one necessarily needs to process the entire message before beginning encryption. AEZ is MtE in the loosest sense, basically another way to say it's a two-pass/offline mode.
Not sure I understand precisely what you're asking. 'Generic composition' is a tricky term, because it tends to hide the assumptions underlying what we're actually composing together. Bellare and Namprempre's paper, which is the most usually cited in this sort of discussion, takes a probabilistic encryption scheme (read: something that takes a random IV) and a MAC, and results in a probabilistic AE scheme. This is obviously not the only way to model encryption and authentication schemes (SIV above transforms those same primitives into a nonce-based AE scheme instead, or DAE with a fixed nonce), but this tends to be overlooked from GC discussions. In some models, MtE and friends is OK. But the truth is that EtM is safe in the widest range of assumptions, while the other ones are more brittle.
That's not MAC-then-encrypt, that's "ECB mode is pretty okay if your message and a nonce fits in your block" plus "let's make an arbitrary-length block cipher". In any case, the result is AEAD, not MAC-then-encrypt.
He must have red Practical Cryptography from Ferguson and Schneier. In any case, it's not big issue. Encrypt-then-MAC is easier to get wrong.