The point is that you can't do the authentication (i.e. checking the MAC) until you have stripped the padding, in this model. So you're processing and performing logic on plaintext data that isn't yet authenticated.

Clearly there are potential finesses in that. A MAC is always going to be fixed length, and a payload has to be variable length, so you are always going to have to put padding in there.

You might counter-argue, well, why not put the MAC at the end, after the padding? But it won't remove the fundamental problem, which is, to authenticate the message by reading the MAC, you're going to need to process that payload (with or without padding bytes at the end), and so you're left making a logical decision about the payload before your authentication process has completed.

In encrypt-then-mac, instead, you do the authentication first, so you never do logical processing on un-authenticated plaintext.