Off the top of my head, DKIM and SPF are somewhat new, using TLS for server-to-server communication is somewhat new and not fully deployed, etc. Mail server operators need to keep track of new developments and update their software and infrastructure to account for them.
There is no possible way that the current state of email is how it will be forever.
According to Wikipedia DKIM was conceived in 2004 and SPF was standardized in 2005 (although designs date a few years before that). I wouldn't call them particularly new (it's almost 14 years now). Even DMARC was here in 2010, that's 8 years.
One recent thing is MTA STS but the progress is slow on this front (from my POV).
Yeah, it's still underway at the IETF. Last session we came close to finialising most of the documents in the UTA working group, which includes MTA STS.
Meanwhile, there's ARC which is still in early stages of deployment, and hopes to fix the indirect mailflow problems of DKIM.
(and of course there's JMAP on the client side, which is super exciting for those of us working on it)
I've seen some providers like Gmail already using MTA STS records and subdomains, but they don't read the records of my domains yet. Still it's an interesting solution.
I'm disappointed in the mailing lists software and configuration "in the wild". Refusing to just change From address and put the original From into Reply To and breaking DMARC (that I've seen some operators just claim "is badly designed") is a very sad state of the world.
I've read JMAP spec but was not pleased with the RPC style design. I've seen "why isn't it REST" and the FAQ says REST is not mobile friendly. Still, reading all these Foo/get methods looks bad to my eyes (sorry, personal preference) an I don't see how it could improve caching (as the FAQ claims). I like the idea of replacing IMAP with something modern though.
Having used a JMAP-style API for years, it works really nicely with batching in a way that other APIs I've worked with don't. Of course, as one of the original designers of JMAP, I'm bound to like it.
It would be quite easy to write a REST mapping for people who like more chatty protocols of course.
I'm not a giant fan of Foo/get either - it's a very recent change from the previous getFoos|setFoos|getFooUpdates naming, and there are pros and cons of the change. I try not to interfere too much with stylistic details like that though.
I'm literally RIGHT NOW writing up an email to the IETF EXTRA mailing list, following up from the email I sent as co-chair to the IETF JMAP mailing list about conflicts for our session in London at IETF101 in March.
We've been working inside the IETF on JMAP since Chicago (IETF98) in March last year.
We're keeping jmap.io up-to-date with the latest spec (including the calendar and contacts bits - calendar is partially underway through ietf calext - contacts are not yet on standards track)
Off the top of my head, DKIM and SPF are somewhat new, using TLS for server-to-server communication is somewhat new and not fully deployed, etc. Mail server operators need to keep track of new developments and update their software and infrastructure to account for them.
There is no possible way that the current state of email is how it will be forever.