Realistically, the length of the domain part is likely ultimately constrained by how large a domain name can fit into a DNS/UDP query packet (alongside EDNS0).
Realistically, people would need to go out of their way to have an e-mail with the domain part longer than a hundred ASCII characters (although considering Punycode, this limit perhaps should be more like 200, for CJK domains...) so if they do, well, it's their problem.
I just don't like the idea of allowing to paste 20 MiB-long text into the input field for what normally is a "short line of text", so there should be some upper limit.
Yes there should, and the maximum size of what fits into a 512-octet DNS/UDP query packet, less header and EDNS0 and whatnot, is going to be that limit, ultimately. Because SMTP-based Internet MTSes that do not look up MX resource record sets in the DNS, and do not begin at DNS/UDP, do not currently exist. (-:
Even if they magically all switched to starting at DNS/TCP, that is still only 64KiB less header and EDNS0 and whatnot. And in that case one also has to allow space for sending the actual resource record set back in the response, DNS/TCP not having DNS/UDP's luxury of truncation, so it's not even as large as that.
I've actually looked at RFC 1034 ยง 3 you've mentioned in another comment, and it states
To simplify implementations, the total number of octets that represent a
domain name (i.e., the sum of all label octets and label lengths) is
limited to 255.
Which, AIUI, corresponds to maximum of 253 ASCII characters (including dots) in the common "subdomain.domain.tld" string format. So "\.{1,100}@\.{1,253}" it is (because, again, it's probably very likely that I wouldn't want to interact in the first place with people who think that the local part of their e-mail having more than a hundred characters is reasonable).
I just don't like the idea of allowing to paste 20 MiB-long text into the input field for what normally is a "short line of text", so there should be some upper limit.