I don't know if it's fair to say email over TLS is really common yet. It's getting there, but Google's email encryption in transit transparency report shows that only 57% of inbound messages to Gmail were sent over TLS. Outbound 72%. https://www.google.com/transparencyreport/saferemail/ (this is largely concerning server-to-server communication, rather than client-server, but server-server communication happens whenever emails are sent across domains).

To be fair those inbound reports are potentially bloated by a lot of spam that no one reads or cares about. It would be interesting if Google disclosed what percentage of messages that end up being read are sent over TLS (or non-spam messages generally). But we can also see that several top 10 sending domains do not support TLS at all (adsender.us, constantcontact.com, grouponmail.*, sailthru.com - mostly advertisers). Luckily the top receiving domains support TLS (which look like other big-name ISPs).

Compared to website TLS, email TLS as commonly implemented has two significant challenges beyond these percentages. First, since TLS is established by the STARTTLS extension protocol within an existing plaintext SMTP connection, it's easy for an attacker who can modify communication to force it to remain in plaintext (simply don't advertise the TLS capability). Second, that previous attack is hardly even necessary: most email senders are willing to establish connections to receivers who present self-signed certificates. The same scenario when browsing a website will show a security warning and recommendation not to continue. The reasoning goes: it's better to use TLS even with a self-signed cert than fall back to plaintext. There's no human involved who can make a judgment call to abort, like there is when browsing a website. So, while email TLS with self-signed certs may be helpful against passive dragnet surveillance, it's little defense an attacker who can intercept and modify the communication: the attacker can simply present his own self-signed cert instead, and the email will flow.

Solution ideas: Devise a standard by which messages can be stamped "TLS only or don't send", and another standard by which domains can declare their intention to support TLS. Senders will remember that the domain is TLS-enabled and refuse to fall back to plaintext; and will require a certificate from a reputable CA under either protocol.

But the connection between this server and that server is not necessarily encrypted. Not every one uses Gmail, Hotmail or other big email providers that (I hope) properly configures for security.