The biggest reason is probably that padding is only required for CBC mode encryption.
What you are doing here is to mix the cipher mode used for confidentiality with the MAC required for authentication. By doing this you are decoupling the padding from the decryption:
- verify authentication tag;
This may not be a problem to create as a separate module, but it would require a separate padding/unpadding mechanism. That padding mechanism also needs to take the authentication tag size (MAC size) as parameter. This is not something that can easily be created using existing API's. Many of those may only contain CBC with PKCS#7 compatible padding which means that the API has to be refactored.
If this is implemented as a separate module then you have created an authenticated cipher mode. There are already quite a few of them out there. Most of them however use CTR mode with an authentication over the ciphertext. CTR doesn't require padding at all, so the problem does not occur in the first place.
One good reason to perform verification before decryption is handling of the plaintext. Decrypted text may have to be handled directly, otherwise it needs to be buffered. In your case you have the added difficulty that you need to store the padding bytes as well, while these are not required for further operation.
So even though your mode may well be secure, it's not very practical compared to many AEAD (authenticated) schemes. There are much easier modes to implement, with CTR / stream ciphers followed by a MAC being the most popular within AEAD ciphers.