In the context of real time connection between sender and recipient
and the ability of the recipient to indicate the allowable media types
and charset values (such as found in HTTP), this is not an issue.
I disagree. It's still an issue for HTML. It's very difficult
to write an HTML parser that handles arbitrary byte sequences
for end-of-line, "<", ">", "\", "!", "&", ";" and other characters
that are significant in HTML. (not impossible, but considerably
more difficult than assuming that those octet values are reserved).
Given that difficulty, it's quite reasonable for text/html to have
very similar restrictions on character sets to text/plain.
(We've had similar discussions with text/enriched.)
Which is not to say that someone can't a more versatile html-like
type and call it application/html.
One consequence of using the same content-type system for both email and
the web is that any class of content-types for use in both environments,
must deal with the needs of both environments.
Keith