Works 99.99% of the time, is unreadable/unmaintainable, makes you understand that the only true way to verify an e-mail is to send an e-mail to that address.
I suppose it depends on what we mean by validate. Running an ecommerce site, I got a lot of mileage out of prompting the customer to fix emails that "looked wrong". We allowed them to proceed if they wanted. A really common one was "user@gnail.com" when "user@gmail.com" was wanted. We used a slightly modified version of https://github.com/mailcheck/mailcheck and found it to be really useful.
There’s no sense being less permissive, if it’s good enough for browsers it’s the baseline expected by browser users. But there’s no sense being more permissive for the same reason.
Huh? My point is that if you expect user input from a browser’s input[type=email], you have little choice but to accept that it will reject emails not matching that pattern. Harmful garbage or not, a more permissive pattern won’t mitigate that.
But allowing too much is better than allowing too little, as usually you have to send an actual email to verify ownership anyways. Any regex more complex than /.+@.+/ fails some valid email address
Or, more insidiously, the address can exist, its recipient can receive mail there, your form can validate it, but your SMTP server can't handle the character to send any in the first place.
Works 99.99% of the time, is unreadable/unmaintainable, makes you understand that the only true way to verify an e-mail is to send an e-mail to that address.
[1] - https://emailregex.com/
PS: Gotta love the Perl / Ruby version