Ehhh no? I am at least not aware of any differences in utf-8 compatibility between browsers or other library implementations. UTF-8 is old and extremely standardized.
Differences in for example, NFC or NFD forms of text, which is relatively common. And even for UTF-8, certain platforms don't properly encode code points beyond the BMP; they do it by encoding to UTF-16 surrogates and encoding the surrogates separately.
Web browsers don't normalize to NFC, NFD, or any other form, and you can control the normalization if you're making a mobile or desktop application. You as the login feature developer get to control and define in your backend interface what form you expect and handle.
In the backend you can choose to hash the non normalized string or a normalized one to the form you want. So this is all tightly under your control. There is no problem here.
That just answers your own question isn't it? It's more work for backend developers to normalize things. If you only allow ASCII, no such work is required.
I don't think there is much of a hassle to implement this. I can only imagine a handful of lines necessary to handle this. Decide which normalization form, if any, you are going to use and then do the normalization in one place on the backend.
And the benefit for the user to be able to use whatever characters in whatever language they are used to is immensely valuable for them. ASCII is extremely limiting and anglocentric. English is universal for people who communicate internationally, but imagine the amount of people who live their lives locally and are only used to writing in their own language. Requiring ASCII of them is unreasonable and one might be excluding a lot of people from using your system.
