Console based mail-clients are very powerful and fast to use. I was a long-time mutt user before I started writing my own mail client, with complete scripting provided by Lua.
Having a real scripting language allows a lot of useful features, at times using mutt felt a little bit too constrained, although it has a lot of features and is very very flexible in its own right:
The article seems to think that everyone should switch away from HTML. But how well does console clients deal with HTML emails. It's not like you can tell everyone to stop sending you HTML.
I use mutt as my sole email client and I don't find HTML to be that much of an issue. The vast majority of the emails I actually want to receive are either text or multipart/alternative with a text option. Now of course, depending on the type of email you receive your mileage may vary.
If I really end up having to read an HTML email those can be displayed "inline" using a text browser such as w3m. If the HTML is mostly text it works pretty well, for instance: https://svkt.org/~simias/mutt-html.png
If however it's image or css-heavy and doesn't work well in text-only form there's still the option to tell mutt to open the email in your web browser. Of course in this case there are security implications so it's probably best not to do it from untrusted sources.
Mutt deals surprisingly well with HTML emails. Most newsletters and other HTML mails usually come with a plain text version as well which Mutt will preferably display. Apart from that, you can make mutt pipe the HTML Email to a console browser for rendering. It works transparently. I've been doing this for a while now
What made me switched back to Mutt was the ability to call subapplications to show you emails. As I always have a browser running, I can tell mutt to show it in firefox, which allows me to watch the HTML mail in all of it's glory (instead of a lynx like dump in the console which I do not like).
I do exactly this too for the occasional mail that I really can't read as plain text.
One concern is that I'm letting through all web bugs and, perhaps, outright malicious HTML. If anyone has a solution for that, something like filtering the HTML, I'd love to hear it.
The general approach is to display the text/plain version of any incoming mails, but if you absolutely need to view the HTML then you'll pipe out to lynx, w3m, or links to view it.
I suppose that mutt could be configured to either display the plain text MIME part of such an email, or pipe the HTML through something like links -dump.
I'm guilty of the Lua feature, and even though it's only covering the existing muttrc API, it can already do quite a lot. The Lua feature is (not yet) turned on by default at compile time (and thus in systems distributions).
I'd be very happy to have more feedback and help to extend further that API and have some great scripts happening!
I think the point where Lua gets interesting is when it can be invoked when a new message is received, or you can iterate over message heads & the message-list(s) and process them automatically.
For example you might have a folder of "backup results", you'd want to mark all that have a subject of "Backup OK" as read, and flag the ones that have a subject of "Backup FAILED" as "important". Those are the kind of tasks I automate with my lua-based mail-client.
You can get more interesting and say "Keep only the most recent 100 messages in folder XXX" which applies whenever you either launch the client, or open a given folder too.
I found neomutt and find it to be nice. One thing that's been annoying me in mutt is that there is no unified inbox. Neomutt integrates notmuch as a first class citizen along with some other niceties(amongst others basic lua scripting).
Having a real scripting language allows a lot of useful features, at times using mutt felt a little bit too constrained, although it has a lot of features and is very very flexible in its own right:
https://github.com/lumail/lumail