I appreciate your reference to RFC-5321. I agree that "the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address."
However, in practice, there exist many services which have GMail's logic baked-in. Or worse, they get overzealous/underzealous with validating the email.
For example, you decide to sign up for e.g. Netflix as alice@gmail.com, which is the address for a Google account which you own completely.
There exists a small edge case where you want a second Netflix account, so you could do that by also registering alice+netflix@gmail.com. Or a.l.i.c.e@gmail.com. In that case, all the emails to these 2 addresses will be directed to the 'main' alice@gmail.com, as you might be aware of. So you'll get messages for more than one, separate Netflix accounts on the same inbox.
I'm not sure if they had this "plus aliasing" from the beginning, same as their logic with the dots.
When I say that there exist many services which have GMail's logic baked-in, I mean that certain apps will forbid you from registering again as alice+asdf@gmail.com or even a.l.i.c.e@gmail.com, because they want to stop on person from 'exploiting' multiple accounts (though Netflix is not one of them).
It is indeed important to go back to the RFC and understand what you are pointing out:
i.e. That, even though GMail redirects messages from both alice+asdf@gmail.com and a.l.i.c.e@gmail.com to plain old alice@gmail.com, it doesn't make it standard behavior, and this is likely not the case for your home-brewed mail server or your enterprise exchange server, which may treat those as separate inboxes, and this can lead and has led to unintended consequences.
I've been involved in the QA of a system which handles payments for a telecommunications provider. It's very common for the customer to land on a payment page, where he essentially clicks on a link, his telecom's account information is pre-filled, like his email address, phone number, and payment amount, and the customer just has to fill in payment information. So even though the telecoms provider can (and in some instances already has) saved a customer's email with a plus sign, the external payment processor's portal mangles it during parsing, converts the plus signs to a space, and then complains about a malformed URL.
As always, this gets filed as out of scope.