The reason it's 72 characters is to allow for quoted text, which gets indented relative to the new text. That would allow a line in an email that's 72 characters long to still fit within 80 characters if it's prefixed with 8 quote characters. For example:
>>>>>>>>This line was 72 characters long, but is now 80 characters long instead.
Still looks pretty
bad on anything
less
than 72 characters
because there's
random
newlines in the
middle of
paragraphs.
Content should be
separated from
presentation.
Additionally 72
characters implies
monospace
fonts which have
been shown to be
less
readable.
Not necessarily. There are times where text should not be wrapped (code snippets, error messages, or log output), but if text is softwrapped, then there's no way to prevent that text from getting wrapped unless you use some time of mark up like HTML or markdown. This requires that the client supports that type of markup which isn't always the case.
There is an RFC[1] that describes the format=flowed option in the MIME headers that addresses the wrapping issue (where text that should be soft-wrapped should have trailing whitespace at the end of each line). That would work with email clients that support that feature and will still appear to be hard-wrapped to email clients that do not. So, unlike HTML or markdown, we don't require those who use clients that only support plain text to update their clients to support a new feature. We can use that feature in clients that support it and have a sensible fallback for clients that do not.
> If text is softwrapped, then there's no way to prevent that text from getting wrapped unless you use some time of mark up like HTML or markdown
Precisely. HTML and markdown separate content from presentation, so content that should never be wrapped - like ```code``` or <blockquote>code</blockquote> is handled properly.
