https://www.mediawiki.org/wiki/VisualEditor/Gadgets/Creating_a_custom_command?veaction=editsource has some TAB characters in the code. These are displayed as arrows. IMHO this is confusing. In many places, tabs are replaced by spaces, so the problem is really minor, but as you can see, there are ways to put tabs in the wikitext.
I'm not sure what you're asking? You are correct that wikitext allows tabs (though they're pretty rare as it's hard to enter one). We intentionally show these with a special glyph (since 2012, I think) to make clear that they're not just one or more spaces. (In visual mode, we also do this for ineffective newlines which don't cause a paragraph break.) Do you think we should reverse this decision? It would make it harder to spot this and fix it.
On a related point, when I copied and pasted a long list, all of the newlines were replaced by little carriage-return arrows like ↵ and all the content was run onto a single line. When it saved, Parsoid fixed everything (thank you, Parsing team!), but it was quite impossible to read, and I nearly discarded the changes to avoid corrupting the page.
As a result of these patches, we will no longer display tabs as "➞" in source mode (NWE). They will still be displayed that way in visual mode though.
I'm not sure if the tab replacement is source mode was an intentional decision, or just something we inherited from VE when we made NWE and didn't think it through. But for reference, let me note that it caused problems in syntax highlighting before and we fixed it back then instead of removing it: T187694 T226478
Also – I was worried that using real tabs could cause syntax highlighting alignment problems when the tabs are used in the middle of a line, I was expecting that browsers would always render them as 4 spaces (or 8 spaces) instead of having tab stops. Luckily this doesn't seem to be the case, and it works fine.