I might be missing something but why would you want to use a terminal interface when a GUI is so much easier?
Resource usage is also about as low as you can get.
You may not have to learn "new shortcuts" (they're pretty standard), but you're perfectly willing to learn an entire text-based configuration scheme?
VIM has its merits for _editing_ code, but that's not what you're doing with e-mails. You're usually just writing them and sending them off. It doesn't matter if you can save a few keystrokes to, say, change a word a few paragraphs back, and you're not producing structured text in any meaningful way.
It's perfectly fine to like the terminal, but you _have_ to admit it is a preference that has nothing to do with "efficiency".
For Yazi, I even created a hardcore Vim configuration that makes it even easier and more efficient for any user familiar with Vim keybindings.
Just one example: look at your email program. Perhaps you have a folder open with 100 emails. Now, imagine that each email is nothing more than a line of text. So, you have a document with 100 lines of text. In Aerc, I can simply jump to the first line (the first email) with `gg`. And with `G`, I can jump to the last email. With `ff`, I filter all emails that have the same sender. With `fs`, all that have the same subject. With `V`, I mark an email, and with `X` or `dd`, I can delete the email. Before that, I can mark all the emails I filtered with `G`. If I don't want to delete them but move them instead, I just press `pf` and enter the first letters of the desired folder where I want to move my emails. I can also set certain folders where I often move emails as shortcuts. For example, `pb` to move emails to the "Brain" folder. Have a look at my simple config: https://github.com/rafo/aerc-vim/blob/main/binds.conf
Once understood, everything becomes incredibly fast.
Tip: try surfingkeys in your browser.
As with most web apps, it's more of a preview than an application.
Given that difference, some people prefer the stability of their tools not changing on them and prefer CLI/terminal work in general. The difference in social contract may not apply specifically to an email client but a given user might be more comfortable in a terminal than in a GUI.
Another short answer: A lot of people prefer to use the keyboard. While it's true you can do a lot of keyboard navigation in some GUIs, but they still tend to be inferior to what you can do in a GUI.
Another answer: Performance. GUIs in general are laggy.
Another answer: What are my choices for GUIs for local mail? I always store mail locally on my PC and use a mail SW to interact with them.
Fundamentally, GUI developers optimize for different things compared to TUI developers.
Finally:
> but why would you want to use a terminal interface when a GUI is so much easier?
I think you'll find that the HN crowd values a few things higher than "ease". Yes, GUIs tend to be easier. Just like using IFTT is easier than writing code. Yet, many people prefer to write code.
[1] I mean OK, perhaps for a thing or two they're better, but not overall.
- integration :: I can create in a single keypress (bind to org-store-link) a link to be inserted in a note (another single keypress, org-insert-link) to pretty anything, a specific place in a file, a whole file to be open with a specific app, a mail message, ...
- end-user-programming :: meaning I can easily have a function (or a script, outside Emacs, maybe) that when a new electricity bill email arrive to my inbox it add relevant information in the relevant contract note, an agenda info, a "special timer" [1] that check my BeanCount transaction for a relevant entry after a certain date etc. With LITTLE coding an user can get a personal BI without a BI monster and issues of feeding it all the time.
GUIs suffer from not being textual enough, TUIs due to the lack of full graphics abilities.
Desktop computing in a network is the most powerful form of computing we have, and unfortunately it's long lost for a modern mainframe model (cloud+mobile) witch is terribly limited and limiting and most not knowing anything else do not even understand the limit.
[1] a function that run at a date, and get re-created when a session restart to avoid loosing the timer after a reboot
Another reason that is more idiosyncratic: If you operate your own email server, you can SSH in from everywhere and use a TUI client locally on the server. This saves the transferring/syncing of emails between client-side local storage and the server; everything is just immediately available.
*Once configured, which is definitely not easy.