The real story here is that OAuth has much wider and far reaching implications than just Twitter apps. I think we've reached the high-water mark of the number of logons and passwords we'll need to keep track of. I see a future not that far off where everything from Credit and ATM transactions to your Facebook and HN logins are all handled by OAuth.
At the adoption rate it's going, I can see Facebook Connect replacing a high amount of "secure" websites like bank accounts within the next few years; and that's unfortunate.
OpenID actually has support for extensions that can allow you to require additional requirements of the AP (authorizing party). This means a bank could, for example, ask for multi-factor authentication from the AP.
I doubt banks will accept generic identity providers in the near future, but I can see them allowing known players in the consumer internet space to provide multi-factor identification.
At the least they could let you identify yourself with another provider and then add additional factors on their side.
Well Twitter only has 2 modes, public and protected.
An app can access anything public through the existing API anyway without authentication.
The only difference here is that you can allow apps your trust to access your private data (or functions, like sending tweets) without giving out your password. As such it's a big step in the right direction.
Twitter apps have been one of the worst offenders for the username/password anti-pattern because of Twitter's use of HTTP-Auth for the API.
* your app can perform more API calls without IP-based rate limiting (which can be a real problem when using the Google App Engine due to shared IPs between apps)
* you can be sure that the user is who he/she claims to be (without a DM hack), which is important for some apps
Unless Twitter change their rate limiting model it makes sense to be be read-only still. This allows you to tap into the 100reqs/hr Twitter allocates to users rather than using up the IP rate limiting for generic requests.
