I would argue that this is a pragmatic argument, not a colonial one. If you see 你好.com written on a billboard, are you likely to be able to visit that site by typing it in on your computer? Unless you have a Chinese keyboard installed (and also know what those characters mean), you simply cannot visit that site, whether or not you are a xenophobe. Nihao.com, on the other hand, is more or less universal accessible.
On the other hand, because of domain restrictions and other such nonsense Chinese websites will often use numbers that sound like words when spoken out loud rather than actual words for their domains.
Imagine being forced to only register 1337-code domains because some other country doesn't have Latin key caps on their keyboards.
Not understanding the local writing system or language does suck for foreigners, but most people in the world aren't foreigners in the country they live in.
Why should countries almost exclusively using the Arabic script be forced to switch between Latin and their normal way of writing because they want to edit the URL between writing comments? Why shouldn't people native in the 120+ languages using Devanagari be able to register domains?
Pragmatically speaking, the lack of proper language support in many non-Latin websites had led to a significant amount of them using images for labels rather than text, making Google/Bing/Baidu Translate worthless for navigating them. If you know what 你好.com is supposed to provide or sell to you, you can find it in a search engine and manually picture-check the domain if you want to be sure; the burden of being available to people outside your target demographic shouldn't fall on you just because a tiny slither of your user base doesn't understand your writing system, but you can opt into making it easier for them to find your website regardless.
Some years ago I had the weird idea of localized domain names. Some mechanism like rel=canonical, that would indicate first that two domain names in different scripts are the same and second indicates the preferred displayed domain name according to the locale of the user. So sesamstraße.example could be displayed as is for de-DE and de-AT, but as sesamstrasse.example for de-CH, assuming both domain names are registered and indicate sameness. With that at least for the main locale of a domain the users do have the minimal courtesy of having the domain displayed right and for other locales there exists an ASCII compatibility display.
But of course giving websites control over the display of their domain name is a major security headache. No idea what kind of stuff would be possible and how it would interact with TLS.
This is probably a reasonable way to handle sesamstraße.example, but how do we manage if skroutz.gr wishes to become σκρουτζ.com? Do we grant them scrooge.com in a non-Greek locale, as Skroutz is the Greek transliteration of Scrooge, or do they get stuck with the letter-for-letter skroutz.com? Will I go to a different site depending on my locale if I type scrooge.com?
What happens when someone registers θεν.com and someone else gets δεν.com, since both transliterate into ASCII as then.com?
That was why I thought that for the reason to work the entity has already have to have registered both (or more) domain names and both domains must, possible in DNS records, indicate their respective equivalence. So no automatic translation, but definitive opt-in by the domain owners.
I had a similar non-related idea for web browsers. Currently domains are mainly lowercase on the web, so we could use a HTTP header to specify the correct capitalization.
capitalization: HarryPotter.Hogwarts.UK
Of course we'd have a lot of lookalike domain problems, like we have with IDN now (:
On the other hand: If you're Chinese and don't know what nihao means, would you not rather be able to simply go to 你好.com? (Chinese might be not the best example here because pinyin is very widespread, but that's not the case for every language)
If you can't type 你好.com you're simply not the website's intended audience.
