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'
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.
There's quite a bit of convenience, and some concomitant security, to using emoji in passwords. Emoji are high entropy code points that are easily visually distinguishable across most language boundaries. A "short" password of just emoji is going to have way higher entropy and be way harder to brute-force/rainbow table than any equivalent "length" (by visual character count) ASCII-only password. That should go without saying. The fact that huge boost in entropy also comes with a massive benefit in how quickly a user can glance at their password and know that they typed in right/wrong often faster than they could if forced to build a line-noise password is a huge bonus. (Related to why Windows 10 experimented with Picture Passwords and a lot of Android users use some form or another of Gesture PINs.)
That said, I think the real solution is of course to eliminate passwords altogether (and yes Passkeys are our best hope right now). But saying that we have to stick to ASCII for passwords because that's a lowest common denominator for keyboards is very much like saying that we should stick only to passwords that you can T-9 on flip phones or send in an SMS or that passwords shouldn't really be longer than 8 characters just in case some Unix system needs to use the old DES-based crypt() function or that passwords shouldn't contain quote marks, semicolons, or percentage signs because those might be SQL injection attacks and you might have some PHP apps that are vulnerable to those. You are letting silly technical lowest common denominator bugs stop you from increasing security for the median/mean user.
(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.)
I'm not trying to invalidate your personal experience. You've seen a lot of good social reasons users probably "can't" be trusted with emoji passwords. but at a purely technical level the number of OSes in 2023 that can't pop up an emoji keyboard if asked is incredibly slim and the number that can't have an emoji keyboard in user space as a software addon is even slimmer. If a device doesn't support at least UTF-8 encodings in 2024 that's an entirely different can of worms (and probably a bad sign for the security of the device itself).
Both the Xbox and PS4+ have emoji keyboards. Apple TV has an emoji keyboard. Almost every version of Android TV and Samsung Tizen and Roku and Fire OS and ….
Go ahead, tell me you have a lot of customer support problems that you don't want to support emoji in passwords. That I can believe. I can't believe it's a technical problem in 2023. Emoji are universal enough now in 2024 that OSes are broken if they can't send/receive emoji and don't have some sort of keyboard to input them. Even if we are still turning off the emoji buttons on password fields because we don't trust users to do it for social reasons rather than technical ones.
As I said, it's not about support for emoji as a class.
It's about support for specific emoji. Different OS's are on different versions of Unicode that support different sets of emoji. The older versions don't support the newer emoji.
So yes, in 2024, it would be incredibly easy to create a password using an emoji on your up-to-date Mac that simply can't be entered on your Android-based TV you purchased 3 years ago, because it doesn't have that emoji even though in supports emoji in general.
So no -- it's not for social reasons, it's very much for technical ones.
And trying to implement a rule like "emoji are allowed but only the ones that were present in Unicode 6.0" is incredibly confusing and opaque for end-users, so it's a better experience just to not allow emoji at all.
Additionally, I'm not sure that supporting full Unicode access (or even just the hundreds (?) of emoji) using a D-pad as an input device would be a good UX.