Many, especially those in business, are not aware of the design of email, and how it is implemented. First of all, let's state precisely what email is: text. It's not MIME quoted printable, inline interpreted, HTML, but plain old 7-bit US-ASCII text, an ansi standard, (MTAs—mail transfer agents—are 7-bit, not 8).
Email did not use HTML until the mid 90s. Perhaps someone decided that we should not have to use asterisks for emphasis, but should be able to use email like a word processor. HTML has become an usable solution for publishing documents to the web. Unfortunately, markup is not the best solution for email. Because HTML tags can be written in plain text (ASCII), there is nothing that stops one from sending HTML as the actual text, not as an attachment. This can be extremely confusing to someone with a traditional email application that isn't aware of inline HTML, (or someone who has not enabled—or more likely had to disable—HTML to assist in identifying spam and viruses).
Attachments, back in the old days, were done with uuencode. Many MUAs (Mail User Agents, the client software that reads your emails) support this. Unfortunately, some web based MUAs do not. The more common is MIME (Multipurpose Internet Mail Extensions). UUencode, and MIME, are both ways of encoding data as ANSI text, so that the information can be transferred in email. However, encoding has its own problems when decoding on the receiving end.
First, what if I don't have a method for decoding uuencoded or MIME encoded binaries? Second, what if that encoding includes characters specific to an operating system, architecture, or character set that I don't have access to?
Please recognize that in English speaking countries, US-Ascii text is the standard for email, without attachments. In other countries, where ISO and unicode standard characters are used, they naturally will not use ASCII, but that doesn't mean that sending email between computers with different character sets will necessarily be able to be read, (hopefully, operating system independent implementations of unicode will solve this).
Many companies that hire programmers to design MUAs don't give their programmers the time to author a standardized, well written email client. They are often designed for a company's internal use, or exclusive to a specific computer platform. This means that you may not have the option to send an email outside of these environments properly. Plus, sending an email that requires interpretation may mean that your MUA is displaying your email using this same interpretation, so you may be sending something different than what you actually intended, (i.e. what you see is not necessarily what you get). This is becoming more common, so you may have to look through several different email applications before you find one that is written well enough to let you send email to the general public. Many web based applications are often operating system, or web browser, specific, or both. Learn how to use your MUA and configure it appropriately. Be sensitive to others who use computers that are different from your own: most people don't care if your computer is newer, faster, and better, nor do they care whether you think your Apple computer, or Microsoft Office suite of tools, is the best thing since sliced bread.
Do everyone else a favour, and save your cutsie HTML, Microsoft Word, or nifty inline background attachments (or even worse, audio background noise) for those you know can and want to receive them, and send plain text, with properly MIME encoded (small!) attachments (when they must be sent), to the rest of us.