Well, other than the fact that it's hard to search for, things should be kept as simple as possible to improve reliability/interoperability. Are you confident that multi-column-wide non-ASCII characters work reliably without causing rendering issues on every possible combination of terminal/shell/OS, including over SSH? I'm certainly not.
Of course you can. I'd argue you shouldn't, but that's beside the point. There is clearly a difference between people being able to do something, and the compiler forcing it on them.
How isn't it? It's setting it by default which is equivalent to forcing it for the huge majority of users who won't even know that such a thing as a flag to disable these emojis exists
They are quite easy to search for actually, because they are sparse and you tend to not get so many spurious results due hitting things that contain your query as a substring. Even then, the glyphs appear inline in the warning message, they are not the anchor, you could still just search for "warning:" like you or your editor have been doing for years. Every operating system comes with an emoji picker, it takes like 2 seconds to use. I'm not sympathetic, tbqh.
If anything, an emoji is easier to search for, as less things would be using it than a general "warning" (or whatever would make sense, as the emoji'd thing isn't the warning itself). Do have to get a copy from somewhere to search for though. It's also much easier to "visually" search for it.
At least in the blog there are a two spaces after the emoji so it can freely draw past its boundaries rightwards without colliding with anything for a good bit; and nothing to its right is used assuming monospace alignment. So at worst you just get a half-emoji.
