Any email address collected by a web application would have a '.'.
As I said, we are not looking for RFC compliance, but rather user error. Missing a dot is user error in 100% of cases in a web application, unless you are installed in and sending mail in an intranet.
As unlikely as an email with @ in the username is, the regex would still match (something like /.+@.+\..+/.
Smartass with the wacky TLD MX record and '@' user name may want to take advantage of your service... so it's down to their monthly subscription vs taking the time to "fix" your validation.
I'm still not sure which approach I prefer, but having been thwarted by zealous validation in the past I lean towards this double-check-on-weird-shit-then-send-mail system.
I will never have enough ___domain specific knowledge to reject a given email address with absolute certainty. That is how much fun that RFC is.
Also, I learned that the local part of the address (the name) can contain pretty much anything, including '@'
So, how would your validation handle my hypothetical, valid email address "@foo"@bar?