Agreed on ASCII not being suitable for a huge chunk of mankind for messaging. That said, in lieu of a better defined set of characters, it
is a reliable set of characters that largely don't overlap when it comes to homograph attacks on human readable identifiers.
The only single character ones in ASCII with noticable issues are 0/O and I/l/1 (this is also why on latin alphabet gift cards, you'll often see these characters omitted entirely). The other homograph attacks on ASCII are mostly font kerning dependent (and even the two I mentioned can still be made distinct from each other in fonts).
I'm not dunking on Unicode here to be clear, Unicode is awesome. That said, bolting Unicode into unique identifiers humans are meant to read is a bad idea because of the homographs. Again; just look at how non-latin alphabet countries generally (don't) work with Unicode in things like usernames.
> As a practical step browsers should ask the user whether they want to allow URLs in a certain language the first time a non-ASCII character is entered.
This would probably help on top of the usual algorithmic blocklists that Firefox and Chrome already use (which largely rely on trying to match what sets of Unicode are used in a domain name to pick between Unicode and punycode rendering).