That's a lie. A mail is sent on failed jobs. The receiving mailbox is by default the executing user (so usually root) There is also an entry into the systemlog which should already be monitored.
The user might not get the notifications because he doesn't pay attention, but cron does notify.
Please don't use the lie word: it goes to intentionality. It's wrong, true: Cron has (for a very long time) been designed to mail and log on failure.
The thing is that a huge number of deployments these days don't run functional mail send, and so the failure states go to /dev/null (in effect)
Also, cron can fail to run: Linux moved cron to a different execution state from BSD, which has also introduced (on linux) the interaction between cron and anacron. Changing the state of cron.d/ doesn't always register in cron, and cron won't always send mail if it doesn't know new things have to be run. The older crontab -e method reliably made cron re-read the state of the file.
(I think this predated Vixie cron, cron existed since time immemorial in UNIXEN. Vix improved things, but the underlying system behaviour was established before he coded in this space)
If someone built a whole product around it - and use it as their marketing pitch when it takes like 30 seconds of man-page reading to find out that it's wrong, I'd argue you have some fairly good reason to assume intentionality.
(That said, yes, I agree that there are failure states in traditional cron that won't alert you with an email, so the service might of course be useful.)
I have deployed many Ubuntu boxes and sometimes been surprised to receive emails - cron (logwatch) usually. Our central SMTP daemon has me as an alias for root, postmaster etc. Don't know why I'm surprised - I set the bloody things up to work - perhaps I'm going a bit senior.
If the messages are going out they probably use an MTA and are logging in to a hosted service, which is something that needs to be set up.
DKIM is the second of the trifecta, SPF first and then DMARC after DKIM. DMARC is when things start to go horribly wrong or wrongerer than normal in the world of email. Mailing lists get funky shortly after you proudly publish a TXT record starting "v=DMARC1; and p=<unwise choice>.
I'm not sure that state of the art is appropriate when describing SMTP. It is what it is and no more, nor less. It transfers a huge amount of data daily, without fuss or comment. Perhaps that is the state of the art - it is in my world: I like stable and boring and just works.
I'm (nearly) a Civil Engineer and I think of SMTP as an odd analogy for concrete. It's fundamental and very boring but can be surprisingly complicated and interesting if you get it wrong. Conc. can burn or get tricky in all sorts of ways if poured in excessive amounts - setting is an exothermic reaction and will work under water as well. Conc can suffer from concrete cancer which is where sea air and a few other factors causes "map cracking" and potentially failure. SMTP is another function that is dumped into the background, forgotten about and relied upon to just work until the wheels fall off.
Of course this is not useful unless you ssh in and read the mail.
But then mail shouldn't be used for notification anyway, so this is not a big deal.
By who? This isn't even almost true.
Local-only (outside of Debian) is generally only found on desktop- or hobby-oriented Linux things like Fedora and Arch -- which aren't really germane here.
But that local MTA you have is not typically something you log in to check your mail, and all of these things are not set up by default.
I'm having a hard time understanding you because you refuse to specify "what needs to be set up" and when you have you've been mistaken.
LAN sending is not being "phased out". Email is not being "phased out". Nothing has changed with email policies on any of these distros for the better part of a decade.
What are you trying to say?
It takes some configuring to make sure crown sends emails to the right place - and without the email going straight to spam. Sure you can setup filters, etc. But that's manual work. Not to mention of you'd rather have it text you, send a message to slack etc.
Also cron can't alert you if you accidentally removed the cron job, the host is down, host loses its connection etc.
Of course they're tested, and you're right they've worked fine for a looooong time.
But I don't care if they "normally work fine", I need to know immediately if it didn't run for any reason. We self hosted a cron monitor, it was free and only took less then a day to add and have fully integrated, including text message and MS teams notifications.