Well, one could argue that it'd help people pick the right one and realize that they actually aren't using URIs anymore if they go outside US-ASCII, which probably is a widespread misconception.
But there would also be practical differences:
o An IRI class can decode the utf-8 sequences, which an URI class can't. (More precisely, it must do this precisely in the transformation from an URI.)
o An IRI class doesn't necessarily have to do the transformation to URI since an IRI can contain wide chars in unencoded form. I.e. it should be able to put together and pick apart the IRI syntax with 8 bit and wider chars on both sides.
o As for the encoding side, extending the URI class to automatically do an IRI-to-URI conversion for wider chars is safe from a standards perspective (i.e. it wouldn't break the URI standard). But in practice it wouldn't be strictly compatible since Standards.URI currently treats 8-bit chars differently.
Last argument applies to the proposed change to Protocols.HTTP.http_encode_string too, btw.