A stronger reason: the point of validating email addresses is to prevent user error, such as putting their name in the email field. It is not to ensure emails are RFC compliant. In fact you probably want to allow non-RFC compliant email addresses because there is a chance it still may work - not all servers are going to be RFC compliant and as a product it is not your job to enforce obscure Internet rules.
Personally I test for @ and . with any characters surrounding.
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.
Personally I test for @ and . with any characters surrounding.