I think an issue with the arguments here is that each side is making its arguments based around quite different standards. Unicode have two standards for inclusion of symbols, one for adding new symbols and one for merging in characters from other character sets.
The rejection is based on the first standard for adding new characters.
The arguments against it seem to be based on taking the second standard as precedent. But I think as far as the Unicode committees are concerned, arguments based on the precedent of whatever random crap was grandfathered in from preexisting character sets do not apply to characters that are not from preexisting character sets. I think any argument that relies on “you already allow all this other random crap” must also argue that this symbol exists in some other character set which ought to be merged into Unicode, or that the standard for new characters should be more precedent-based/different, but I don’t see any such arguments other than some implied “common sense guess as to how one expects Unicode to work”
So the smartest way to go about this is to create a whole new character set for external link symbols? That seems like a really roundabout way to get this thing accepted.
One has to make a better argument for the external link symbol getting a codepoint assignment. TFA, for example, makes an argument based on emojis -- certainly that's strong enough to blunt the UTC's rejection rationale, but perhaps not enough to win approval outright.
Addressing all the arguments used in the rejection is important, of course. The fact that currently images are used is hardly dispositive: that's business as usual for missing Unicode assignments!!
But there are probably stronger arguments for rejection than adoption than the UTC made that it could make the next time this comes up.
The best argument for rejection that I can think of has to do with layering. An external link character isn't very useful without the actual external link, but the link belongs a layer up: not in the text, but in the markup. Well, if the link belongs a layer up, why not also the symbol? Alternatively, more markup can move into Unicode. There has been and will continue to be some pressure to move more semantics from markup to text, but it's probably best to resist that pressure.
On the other hand, a solid argument for adoption may involve text rendering of HTML. Think of lynx/elinks and other such browsers, which can't use images. An external link character could prove useful in distinguishing the rendering of linked text from, say, underlined non-linked text.
I'm surprised these arguments didn't come up. Or maybe they did -- I've not gone down the rabbit hole on this one, and probably I won't.
The rejection is based on the first standard for adding new characters.
The arguments against it seem to be based on taking the second standard as precedent. But I think as far as the Unicode committees are concerned, arguments based on the precedent of whatever random crap was grandfathered in from preexisting character sets do not apply to characters that are not from preexisting character sets. I think any argument that relies on “you already allow all this other random crap” must also argue that this symbol exists in some other character set which ought to be merged into Unicode, or that the standard for new characters should be more precedent-based/different, but I don’t see any such arguments other than some implied “common sense guess as to how one expects Unicode to work”