>Ability to view the email in different languages. Ability to modify the email data. Ability to preview email in desktop and mobile.
All those things would be solved by sending text email. Whereas this overly complicated markup langage to HTML w/ javascript, and server response dynamic stack of programs will fail completely if JS doesn't execute just right in the mail client or there's some connection issue.
I guess for for-profit contexts one cares more about aesthetics than functionality.
Plaintext email certainly wins in implementation simplicity/elegance, and in cybersecurity, as Drew DeVault has written about. [0][1] That said, there are real advantages to rich emails. Embedding images and tables, and colour highlighting, can be useful for clear communication.
The HackerNews thread about [0] has much discussion on this topic.
This might be pedantic, but iirc email clients don‘t execute any javascript due to security concerns (at least that was the case when I worked in email marketing 7 or so years ago).
The javascript is basically only used for templating, defining reusable components and rendering the static HTML together with inline CSS which does make a lot of sense because writing „bulletproof“ email components that work on every client is a huge amount of work and you would generally like to keep the amount doing that to a minimum.
In my experience every company uses some type of email templating system, some off the shelf, some built in-house, I actually got my start in (actual) programming by building one for my team.
I solved this same problem in a less fancy way: https://thoughtbot.com/blog/building-templated-emails-with-m...