That's a cop out. You could equally say that new emojis shouldn't be added because you should use inline images for those. Or RTL markers shouldn't be added because you should use dedicated text styling for that.
There are a ton of places that don't support superscript markup.
> You could equally say that new emojis shouldn't be added because you should use inline images for those.
If emojis weren't allocated out of compatibility concern, this would be exactly my opinion from the day 1. To be honest I'm not still happy with the current emoji assignments and semantics. Not even Unicode people are satisfied either, there are numerous proposals for replacing emoji with something else (example keyword: QID emoji).
> RTL markers shouldn't be added because you should use dedicated text styling for that.
> There are a ton of places that don't support superscript markup.
Unlike most text attributes, bidirectionality is an intrinsic property of abstract characters and thus absolutely within the Unicode's scope. Ideally you can't and shouldn't make some LTR character to behave like RTL characters or vice versa. Bidi control characters only exist to correct automatic rendering, and can be presented out of band (the Bidi specification is explicitly designed for this use case in mind [1]).
> You could equally say that new emojis shouldn't be added because you should use inline images for those.
Well, that's really a better solution. Or a unicode character that allows you to set a pixel on a 256x256 grid and one to compose them. Strike that. Better not give anyone bad ideas.
[1] https://unicode.org/faq/ligature_digraph.html#Pf8