Checking my mail archive, the HTML part of multipart messages is on average 5 to 10 times larger than the plaintext part. Such a factor is essentially never irrelevant, even with decently fast connections it often takes me a minute or so to download a day’s worth of e.g. debian-user messages.
Similarly, I’d be quite annoyed if my local IMAP cache took five to ten times as much space than it does at the moment for no reason whatsoever (other than filling up an extra 8 to 18 GB).
This preference is based on the assumption that the extra information conveyed in the HTML part of the email is worthless, which may not be the case.
I can see from the downvotes that some HN users are excessively passionate about their plain text emails, but many people do prefer the extra formatting and layout that a well-constructed HTML email can provide.
This can be observed in general by the fact that almost everyone uses web browsers like Internet Explorer, Firefox and Chrome - rather than Lynx.
For people who are sending email with no HTML features it seems weird to inflate that email with unused unseen cruft.
Many people send email that makes minimal use of HTML features. They perhaps have an auto-appended footer with useless information that is in italics. It's debatable whether the extra size of HTML email is worth it for such minor formatting.
But no one is suggesting that the tiny number of people who "prefer the extra formatting and layout that a well-constructed HTML email can provide" should use plain text emails.
> This can be observed in general by the fact that almost everyone uses web browsers like Internet Explorer, Firefox and Chrome - rather than Lynx.
No. Poor quality design has meant that much of the modern web is unusable for many web browsers. Not just "specialist" browser such as Lynx but for some versions of the browsers you list.
> [...] but many people do prefer the extra formatting and
> layout that a well-constructed HTML email can provide.
I think that's where the issue is --- nearly all HTML e-mail that I encounter is not of the well-constructed variety, and thus doesn't merit the extra overhead.
In a non-professional context (mailing lists, personal communications), I do just fine with plain-text; in a professional context, I loathe receiving e-mails that utilise what HTML brings because it's nearly always abused in the form of excessive signatures or massive legalese footers shrunk to 6pt, italicised, and rendered in nearly invisible grey.
Any content that really requires the extra formatting and layout offered by HTML would probably be better sent as an attachment anyway. I've lost count of the number of times I've had excerpts from spreadsheets or brochures pasted into an e-mail which have then been mangled in transit, or stretch way off the screen.
I've yet to see a "well constructed" HTML email that was sent by a human as part of an email conversation.
I've seen plenty of poorly constructed HTML emails sent by people who decided that since they can have twelve different fonts in five sentences, with italics, bold, outline, underline and strikethrough thrown in, they should do so. It's almost like they have set themselves a challenge to use every feature of their email client in every message.
Plain text, on the other hand, always looks sensible, well-formed and well constructed to me. This leaves it to the sender to write something worth the effort of reading.
Well, in practice, HTML in emails almost never is worth it, and that's not because richer markup is necessarily a bad idea, but because people don't grasp the concepts, and because what plain text provides almost always is actually powerful enough, while being a lot easier to use - which is important, given that emails tend to be read once, in contrast to websites, which tend to be read lots of times, so more effort in composing them is justified.
In order to compose an HTML email that actually takes advantage of the power of HTML, you have to grasp the abstraction between what you see on the screen and the underlying document structure, and how that underlying structure might be rendered by different receiving MUAs - something that most users don't grasp at all, and also a problem that's not particular to HTML email, but one that is well-known to affect all WYSIWYG authoring tools, and one that is known to be particularly problematic with document types that can be rendered very differently depending on the "medium".
By contrast, the typewriter style interface of plain text email composition is something that's completely intuitive to most people, and people easily succeed at composing an email that reliably will be rendered at the receiving end exactly as they expect - and most of the structure that you need for most email correspondence can actually easily be constructed manually from individual characters (headings, paragraphs, lists, numbered lists, ...).
Also, it can be observed that almost everyone reads books and journals typeset with TeX or DTP software. That's not exactly a good reason against creating your shopping list with a pencil.
Similarly, I’d be quite annoyed if my local IMAP cache took five to ten times as much space than it does at the moment for no reason whatsoever (other than filling up an extra 8 to 18 GB).