We also have the bonus of knowing exactly what web and git clients the whole team is using, but for more open projects it might be an issue.
Concensus seems to be that they should be avoided.
I really don't even like seeing those stupid READMEs full of them.
They could be marginally useful as quick indicators for skimming git log output. In a well orchestrated system, you could do something like add 2 emojis to the front of every commit/MR indicating the reason for the change (bugfix,feature,etc) and the component of the system you touched. I.e. a bug emoji and a lock emoji for a bugfix in the auth system. As long as the info is kept high level, brief, and most importantly consistent (i.e. every MR has 2 emojis, or every MR has 4 emojis, there is no situation where an MR would have an extra or missing emoji), it should be really easy to skim. I don't know if that value is worth the pain of having to bicker about whether a particular emoji should be labeled with bugfix vs enhancement and such.
I wouldn't encode any information solely in emoji characters because of the relative difficulty of displaying them in consoles and of automatically parsing them in something like bash. If I was going to do that emoji tagging, I would make it a requirement that there are accompanying tags in the message (or make a tool that automatically appends them based on the emojis).
Not all Emoji will be rendered correctly in all Git Clients.
Tags such as [BUG], [FIX], fix:, etc is unambiguous, unlike some Emojis used.