Until such a feature is implemented, you could try:
ExecStart=/bin/bash -c 'shopt -o pipefail; mycommand | mail -s [email protected]'
Certainly not as convenient as MailTo=, but a lot less complicated than using OnFailure= with a separate service that tries to mail you the output.
But to be honest, not having to do <shell> -c <exec this or send me an email> ever again is one of the reasons why we're doing the whole systemd thing, and one of its big promises. If it comes to writing shell mantras again, I might as well use vixie cron (or one of its descendants) and benefit from 30+ years of bugfixes across more Unices than I can name, plus the acquired wisdom of the Interwebs.
Edit: plus... does this still allow you to get the other goodies, like being able to specify environment variables for a specific job?
As for 'exec this or send me an email' -- I would also much prefer to see this be done by systemd itself. Fortunately bash's 'pipefail' feature plus bsd-mailx's '-s' flag make this reasonably quick and sane; I wouldn't even bother to attempt it if I were stuck with POSIX sh or if the mail command lacked the logic to not send the mail if stdin is empty.
I thought that environment variable passed via the Environment= options might not be correctly set, but it seems they are :-).
Every time someone asks "why should I use systemd instead of cron" they get these (technically correct -- the best kind of correct!) answers about how systemd timers allow you to attach jobs to cgroups, define dependencies, test unit files separately vs. changing crontabs for 1 minute ahead (which I don't think is a "cron idiom" -- I've certainly never done i -- but we all have our weird hacks), and how it has built-in jitter options and per-job environment settings and whatnot.
These are all very relevant for real-life workloads of super advanced cloud systems, I'm sure. (Which I'm not saying in a derogatory way. I haven't written back-end code in like 12 years now, the things that are happening there today blow my mind. I know these are complex systems so I'm pretty sure they have complex problems which have complex solutions.)
But guys, I just need to run a bash script every day at 2 AM. 99% of us just need to run a bash script every day at 2 AM. This has worked reliably in cron since practically forever. I have grumpily learned the new way of doing it but I can't really justify the time I've put into it, nor the (very extensive) troubleshooting that was involved in it. I just woke up one morning and sat down in front of a Linux machine and I found out that there's a new way to run things at 2 AM.
If you want to woo me with cool systemd-timers features, tell me that it finally has an equivalent to cron's MAILTO, so that I don't have to write yet another systemd unit file that wraps a script written by me if I want to get a notification when a job has failed, because somehow that hasn't made its way into the "everything but the kitchen sink" list which otherwise includes things like attaching jobs to cgroups.