The argument here is that checking complex validation is a fool's errand. Yes, you can write a fully validating regex for RFC email. In fact, it should be possible to write a regex shorter than the one that gets passed around since the 90s, because regular expression engines support recursive patterns now. (Part of the reason that old regex is so complicated is because email allows nested comments (which is insane (how insane? (Lisp levels insane)))).

However, it doesn't get you much of anywhere. What you really want to know is if it's a valid email or not, and the only way to do that is to send an email to that address with a confirmation. The only point of the regex is to throw away obviously bad addresses. For that, checking that there's an @ symbol and something for the user and domain portions is sufficient. I'd add needing a dot in the domain portion, but it's not that important.

Classically, it was argued that emails don't even need a domain portion when things are done for internal systems, or that internal domains don't need a tld. In my personal experience, this is rarely done anymore and can be safely ignored. Maybe some very, very old legacy systems, and if you're working on one of those, then sure. For everyone else, don't worry about it. You're probably working on publicly accessible systems, and even if you're not, most users are going to prefer using their fully spec'd out email address, anyway.

Where did you get that "RFC standard" regex? It doesn't allow domain names with one component RFC5321

Neither does it allow spaces in quoted string, as per RFC5322

This, 👋@✉️.gg, is already a working email address in most clients and if RFC6532 ever gets accepted, it would be officially recognized as such.

My point isn't to make your regex bad, just that it doesn't validate or invalidate an email properly. Nothing stops me from giving you and invalid but syntactically correct email after all.
You have to send an email anyways to verify, so the most you can check is the presence of one @ symbol.