From a technical perspective, what you're talking about is something that would be very brittle and liable to break because of changes Twitter make to their login pages.
It's also relying on functionality that may be treated in the future as an attack vector and locked down by either Apple or Twitter. e.g. like the changes a lot of web browsers made to cross-domain ajax posts, pop-ups, pop-unders, etc.
Everything you are describing being "locked down" happened within the context of the browser world, not to webviews you control. Again, once you are in control of the webview you can do anything. Think of this way: you could just implement your own HTML renderer, at which point, once again, nothing anyone builds in will matter. In fact, why bother embedding a webview at all? Depending on how they implemented the login, simply download the HTML source code as plaintext, then issue the post of the form yourself -- no browser required. Each of these is slightly more abstracted, but you get the idea.
I agree with your point that this may be brittle, but that's kind of the point I'm making -- you're getting zero new security benefits out of it and introducing the possibility that many apps use a worse technique to get what they want done. Also, if you are just manually filling out a form I wouldn't worry about brittleness too much, you're just looking for two text fields and then submitting whatever form contains them yourself. Unless Twitter actively starts trying to create fake form elements or something I doubt anything would break, and even then, is this really what Twitter wants to get in the business of building, tricky forms to swat third party apps?
It's also relying on functionality that may be treated in the future as an attack vector and locked down by either Apple or Twitter. e.g. like the changes a lot of web browsers made to cross-domain ajax posts, pop-ups, pop-unders, etc.