Nah, if someone sends me HTML it gets parsed into plaintext and if it doesn't work I don't care what's in it. You want to send me a pretty document - feel free to send me an attachment or a link. HTML emails are always ridden with superfluous disclaimers and signatures not using the -- convention, they're a waste of time.
I sympathize, but I'd much rather somebody send me an HTML email than an attached Word document, which is the next likely candidate in most workplaces.
There are valid uses. My hybrid photo-sharing/blogging service lets you send an email update with thumbnails inline, so you can tell family/friends about your latest doings without making them click a link out. http://ourdoings.com/
I suppose you could generalize this by saying HTML email is useful when you have images that are informational, not just decorative.
at the least you can be sending multipart/alternative to include both a text/plain and html body, so you don't have the horrible situation of people getting html source dumped at them. Most webmail clients these days support 'rich content' to a reasonable degree, but a lot of people still have old desktop clients that'll just give up and throw it all at them.
That said, maintaining 2 templates or deciding exactly how to handle the formatting of the text version can be a hassle. I'm curious how others have handled this problem.
Sending HTML-only email is still a large spam flag, even at major ISPs, independent of the concerns about client compatibility.
At PostageApp our solution to the problem is a templating engine where you can write your HTML/CSS separately and we inline it at run time to ensure client compatibility. We then provide a separate Plaintext tab with an 'import from html' function which does most of the work for you for managing dual formats.
