A terminal still can't render images. Unless you're doing some level of framebuffer shenanigans, that is, but I'd wager most people work on a GUI with terminal windows, not full screen terminal VTYs.
We've got this wonderful invention called the graphical user interface.. why not leverage it?
There's an unexamined assumption underlying your comments: Namely that because something is terminal-based, it's 'not modern', and that the GUI unambiguously represents progress on all fronts for all uses.
But consider: in the 30 odd years of GUI prevalence, there has never been an example of a GUI email client as simple (for some value of simple), functional, and powerful-for-power-users, as Mutt and Pine.
I think it's at least worth considering the possibility that you're asking for is the equivalent of wondering why you can't just have a lighter-than-air balloon made out of lead; the possibility that GUIs might represent progress along some axes (discoverability and approachability) while fundamentally constraining you along others (power, functionality).
>But consider: in the 30 odd years of GUI prevalence, there has never been an example of a GUI email client as simple (for some value of simple), functional, and powerful-for-power-users, as Mutt and Pine.
That's exactly my point though - why do most email clients suck so bad? Slow and bloated are the most common adjectives thrown around (Outlook, Thunderbird), and if not that, then there's the weird UI's (Eudora, The Bat) - and then there's the terminal clients, while very nice, very fast, very functional, completely ignore all progress made in user interfaces over the past 20 years. (Pine, Mutt)
It's like you have a choice: Modern, Fast, Functional. Pick any two.
This is something I can imagine coding . Give me something like Pine or Mutt that works in a GUI and can render HTML and images, but still "looks" and runs like Pine or Mutt. Imagine it in your head for a moment - the same UI, but instead of html strewn about everywhere, you have actual rendering of html and images (via choose-your-favorite engine, leaning towards Webkit) in the same window.
I don't think that HTML rendering, speed, and functionality are mutually exclusive goals.
I use alpine and have set w3m as the HTML reader in my mailcap file. w3m also displays images in HTML. Alpine is able to display most HTML emails just fine, but when it fails, I simply press V (which shows different mime parts of the message) and Enter (by default the focus is on the 2nd part, which is text/html; Enter launches the default html browser, which is w3m that displays the message). This gives all the benefits of alpine, with the option to display html+images in the same terminal if I need to.
They are usually remote linked content, so your client disables them for privacy reasons. How often do you really click "display images in this message" versus "meh, I got the message and I can spare the rounded corners on this advertisement and instead not send a req back to their server notifying them I've read it".
But I get what you're saying. Without HTML emails we'd all still be looking at those ">" characters for quoting. Hideous. At least now we got dark blue vertical bars. I for one couldn't live without them. That's progress!!
We've got this wonderful invention called the graphical user interface.. why not leverage it?