It's probably better if it shouldn't. It's generally better to prevent passwords from containing characters that can't be entered on a decent proportion of devices you may encounter.
Emojis are particularly problematic because new ones keep being added which require OS upgrades, and you might find yourself needing to log in from another device that just doesn't support those emojis yet.
Also it's not like Unicode makes everything easy. For example, you have to remember to normalize the password before hashing. Otherwise something as simple as "ñ" may be a totally different byte sequence depending on which device you're using.
It is no longer realistic to pretend that only ASCII exists and try to get away with that.
Python 3.10.12 (main, Nov 20 2023, 15:14:05) [GCC 11.4.0] on linux
>>> "ñ".encode("utf-8")
b'\xc3\xb1'
>>> "ñ".encode("utf-8")
b'n\xcc\x83'
A naive hashing algorithm will hash them to different things.For way too much information on this, see: https://www.unicode.org/reports/tr15/
Even a lot of Unicode-aware code written by a developer aware of at least some Unicode issues often fails to normalize properly, most likely because they're not even aware it's an issue. Passwords are a case where you need to run a Unicode normalization pass on the password before hashing it, but, unfortunately, if you're already stored the wrong password hash fixing it is rather difficult. (You have to wait for the correctly-incorrect password to be input, then you can normalize and fix the password entry. This requires the users to input the correctly-incorrect password; if they only input an incorrectly-incorrect password you can't do anything.) I'd suspect storing a lot of unnormalized passwords before learning the hard way this is an issue is the majority case for homegrown password systems. You hear "don't roll your own crypto" and think reaching for a bcrypt or scrypt library solves it, but don't realize that there's some stuff that needs to be done before the call to those things still.
Emoji weren't officially supported until Unicode 6.0, though there are a subset of current emoji (less than a quarter) that work on Windows 7 in practice.
Meanwhile the current standard is 15.1.
There's no security or convenience necessity whatsoever for supporting emoji in passwords, but inconsistent OS support is an excellent reason against it.
(I've spent about 6 years of my career running video streaming services... People watch a lot of video on TVs, it turns out, so you probably don't want to let them put these sorts of characters into their passwords when they sign up on mobile or computer devices.)
The upper layer might change now and then, to give a veneer of modernity. But just like Windows being built on 90s technology, the stuff underneath could be even more ancient.
Would it, really?
P0 would probably be "10% of our customers can't submit an order." Or "20% of our vendors are experiencing 404s."