They can't. That's my point. If they would text you a code and ask you to enter it, then they can infer successful delivery. They don't do that, which means that you can turn on 2FA against a phone number you don't own and completely lock yourself out.
Better yet: They don't have any concept of "trusted devices", so you have to do the 2FA dance every time you log in regardless of whether you've 2FA authed on that device before or not. This means that if you've lost your phone and your desktop session has expired, you can't get back in to turn 2FA off, again meaning that you're completely locked out.
I think if they had a concept of devices to permit "trusted devices", they'd also have a way to do "has already seen this notification on one device, so don't display it as new on other devices".
Twitter must really be a disgusting mess architecturally; they have a decent number of competent employees, so it's hard to imagine things like this persisting otherwise.
Not really; you can just set a cookie that indicates that the device is trusted for 2FA. It's no more damaging than a session cookie if hijacked, can be protected by TLS, and doesn't require any special server state.
On first login:
Login sends credentials, no cookie. Provider verifies credentials, doesn't have 2FA verification, sends 2FA challenge. Upon completion of challenge, provider sets session cookie + 2FA cookie.
On logout, the session cookie is destroyed, but the 2FA cookie is not.
This way, you can gain the power of 2FA (someone stealing my credentials won't be able to log into my account) without the hassle of it (people using stolen credentials won't be logging in on my own computer, so I can trust this computer to bypass challenges for 30 days), and you don't have to add any server state that is aware of any particular computer, save for some value which is tied to the cookie. For bonus points, the server maintains a list of 2FA cookie tokens, and allows them to be revoked, so if my laptop is stolen, I can log in on my desktop, revoke my laptop 2FA cookie, and the 2FA bypass won't work from it anymore. Slightly more work, nothing really significantly difficult, but substantial increase in usability without any real sacrifice of security.
For webapps, yes, but I'm not sure how they could do it that easily with iOS integration. I'm pretty sure Twitter views iOS/Android as much more important than web.
(although, most of their hacking/account hijacking probably happens over non-mobile. If they had a way to improve web login security and strongly separate out mobile integration logins to use a weaker system, that would work too. Although I think it wouldn't be too hard to present to Twitter as a mobile client when you're really a fuzzer or attack script.)
To be fair - you do need the Twitter account password to do that - and if an attacker already has that it's too late to protect anything. So you're down to protecting against people who 1) bother going in to enable TFA, 2) type their mobile number in incorrectly, then 3) click through the "did you get a text from us" without reading it. Sure, making them type in a code you texted them would reduce _a_ category of problems, but I suspect it's a reasonably small category (I'd quite likely have felt OK to accept that problem in order to rush something out quickly with the intent of "fixing it" in the next week or two, but then I've never run anything at Twitter-scale, and I suspect a tiny percentage of users with problem adds up to a _lot_ of support time very quickly there.)
Better yet: They don't have any concept of "trusted devices", so you have to do the 2FA dance every time you log in regardless of whether you've 2FA authed on that device before or not. This means that if you've lost your phone and your desktop session has expired, you can't get back in to turn 2FA off, again meaning that you're completely locked out.