Just having learned how to use a TAB character even without an external keyboard, I saw some strange effect:
My line get´s automatically wrapped, when using TABs …
I attach a screenshot that shows what i mean.
I’ve tried this on my iPhone 8+ and my iPad. I see the 13th tab always pushes the next character to the next line. It looks roughly like this is the width of an iPhone screen in portrait.
It therefore looks to me like Draft is impementing tab stops rather than just a tab as a pre-set equivalent of spaces.
i.e. if I type “{tab}1” on one line, “0{tab}1” on the next, “00{tab}1” on the next and “000{tab}1” on the next, all of the 1s line up vertically.
Therefore it just looks like Drafts is using a tab stop set-up that is probably set to match the width of the narrowest screen - a portrait iPhone.
… but this is just my guess based on the behaviour I’ve observed.
Yes, it feels like a problem in Drafts, so i posted it here …
And Tab Stops is a very good explanation for the behavior!
But this just means, that the list of possible Stops is just too small and needs to be enlarged.
Hopefully, we can get this fixed 
On the assumption this is a maximum tab stops issue (and note that tabs working to tab stops is historically the right way to implement their use), then a maximum based on the minimum screen width of a device is in some ways a reasonable constraint. But I can also see that in some cases that dealing with more tabs on wider(?) screens would be highly advantageous.
Being able to set it as higher might bring some subtlety into the right solution. The drafts are auto wrapping lines, so if you set the maximum tab stops to something larger, then how would this look and work when switching between devices and orientations?
Also I’d not even considered it earlier, but how are font sizes and margins affecting it?
Not insurmountable issues I’m sure, but perhaps more involved than might first appear when taking into account different devices, screen sizes, margins, font styles and font sizes.
I’m now more intrigued by this behaviour and what options there might be going forward; or perhaps hidden somewhere already in the app that I’ve overlooked. 
I tested Editorial, Textastic, 1Writer and ByWord as the closest companions:
To spare you the screenshots i made:
-
Editorial works fantastic and flawless!
It just wraps the text and the tabs correctly when in portrait mode, as you would expect.
Perfect! -
Textastic is a bit buggy
It wraps, but only at the columns where it would wrap in landscape mode - so you need to scroll to see the whole line. Not good! -
1Writer is as buggy as Drafts
Don´t see much difference. -
ByWord is so buggy, that i cannot spare you the screenshots
But the wrapping itself works fine.
Only the TABs are just wrong.
YES, i separated the numbers by TAB characters!!!
Drafts does not try to set tab stops - it’s the default UITextView implementation. It’s never done anything with them and no one has every brought it up - but I’ll make a note to take a look.
Editorial does not use UITextView, so that is likely why it’s different.
Ah, and UITextView is from Apple, i suppose.
Thanks for the information, i was not away of this and thought the developers of apps did this.
As for Apple, they don’t fix their stuff … still no calculator for iPads, still no „Select All“ in the Mail App, still no default for disabling Siri, and so on.
Sad thing.
So, for now, no TAB separated tables in Drafts 
I’ve been having the same issue on the Mac. When using TAB, frequently it wraps to the next line, no matter the window width. The only way to avoid it is setting TAB to insert spaces, which is a bummer.
I thought I had resolved that a long time ago, will revisit today and make sure adequate tab stops are defined.