Not every application that was built on APi v1 has an easy upgrade path to API v1.1. The requirement of authentication is a big hurdle for a few classes of applications.
Additionally, just because the data is “public” doesn’t mean an application shouldn’t need to identify itself from the other millions of applications making requests to the API. It’s really no less public, but I don’t think you came here to argue the relative publicness of data.
It sounds like each of these 25,000 mobile apps are individual applications, and each should have their own API key. That was the intended model in API v1, and it’s still the model in API v1.1. It was just easy for you to choose a more frictionless model with unauthenticated API requests being available.
It’s understandable that end-users of these applications shouldn’t necessarily need to authenticate with a Twitter account, and app-only auth might be the right solution on a per-app basis for these. Though Tweets are much less potent when they are not actionable, and the best way to make them actionable in an application is by leveraging user-based auth (or perhaps web intents).
Ideally your framework provides the ability for the developer of these applications to provide their own API keys. Once application-only auth is released, you would likely leverage that on a per-app basis. Otherwise, you can go ahead and implement with full user-based OAuth 1.0a today.
