That's not universally true - there's a remarkable amount of TLS/SSL encrypted email-in-transit, either via STARTTLS ESMTP commands or SSL over port 465 (and 993/995 for IPAM and POP3).
I don't think there's a way to guarantee your mail always travels over TLS/SSL secured connections, but I suspect more of it does than you think.
There's a straightforward way to make sure your email is always encrypted in transit: encrypt it before you send. No promises about making sure your email can always be read by the recipient, though...
And here's the problem. Email needs to be able to be read by the recipient, so until a significant portion of email recipients can handle encrypted mail - the NSA doesn't need to attack my encrypted email storage, because enough of my correspondence ends up in cleartext in gmail/hotmail/yahoo et al.
This is a hard one to solve. GPGmail seems to get broken with every Mac Mail.app release. Vast numbers of people rely on webmail - which'd need server-side or in-browser GPG decryption. My Mom's not going to use command like gpg tools. How the hell do we bootstrap our way up to ubiquitous encrypted email?
Hm, should be easy enough to have some browser plugin that lets you select a text/data field and recipient list field and encrypt it with the appropriate key; and to do something similar for recognition and decryption of fields.
I think there are complications though - you need to be very sure that rogue javascript can't dig around in your plugin and extract my private key. I'm not sure how securely sandboxed plugins can be.
What's the normal procedure for making a call whose output depends on a file that must be kept secret? Is there a typical OS API pattern that's seen in the various programs like ssh, scp, and so on?
I think the one of the problems is that software like GPG and OpenSSL go to a lot of trouble to make sure private keys don't hang around in memory for any longer than absolutely required - minimising the risk of having the OS preempt the executing code and write the key out to swap (or having malicious code slurp it up out of ram). The bare-metal hoop-jumping required to get that right might not be possible in the context of a browser plugin.
I don't think there's a way to guarantee your mail always travels over TLS/SSL secured connections, but I suspect more of it does than you think.