I do this, and it works for me (as in, the backups run fine, and I have done several restores). I use bacula, which supports it. For my money, pointers to getting this right include:
1) The decryption key is kept (unencrypted) on a CD-R, not in my head. There are several copies of the CD-R, and none of them is with me. I only need to do restores once every few months, and frankly I'd probably forget a password that I used that infrequently. This also means my security isn't limited by the length of a memorable passphrase.
2) The backup software needs to support this already; don't start hacking this into your favourite tool, because you may get it wrong, and you won't know until it's vital that it work (ie, restore time).
3) You've a point about bit-flips, but those can ruin any backup. I clean my tape heads every time the drive requests it, rotate the tapes every few years, and above all keep lots of incrementals. If a bit-flip really did ruin yesterday's incremental, I can always go back to the day before, which will save most of my bum.
4) Document the restore procedure. Encryption always complicates things, more if it's done well, and you don't want to have to rediscover the wheel when you're under pressure to get the accounts database back. I wrote a short README with lots of detail that's very specific to my setup (a real step-by-step guide, all pathnames explicitly listed, that sort of thing) and it's burned to the same CDs as the decryption keys.
5) Above all, test it a lot. You should be testing your restores regularly anyway, but once you've done something clever like this it becomes absolutely critical that you have confidence that things are working as they should.
Pros arising from this practice include not having to care when offsite storage loses a tape or two, as - being only human - they do from time to time; securely destroying old tapes is easy (throw in bin); and having all my file systems encrypted on-disc is no longer undermined by having a stack of unencrypted backup tapes in the fire safe next door.
Best Answer
The practical problem is that not every SMTP-compliant (the RFC is quite old) server can speak TLS to your server, so you may miss receiving some email messages.
The philosophical problem with this is that its impossible to tell how the email gets relayed after (or before) it arrived at your server.
This means that the email may have already been transmitted in plain-text via a relay already.
Anyone serious about protecting the contents of their email should actually encrypt the body. With encryption en-route its always plausible its been transmitted in plain-text already.
So, to answer your question enforcing encryption at the SMTP layer is probably pointless, increases your chance of missing email and there is no guaranteed beneficial payoff.
Edit: This refers to SMTP enforcement for the purposes of relaying, not submission of email. In mail submissions encryption should be enforced since the SMTP conversation (not the actual email) possibly contains authentication credentials.