OAuth 1.0, RFC5849, April 2010: "if the client is a desktop application with freely available source code or an executable binary, an attacker may be able to download a copy for analysis. In such cases, attackers will be able to recover the client credentials. Accordingly, servers should not use the client credentials alone to verify the identity of the client. Where possible, other factors such as IP address should be used as well."
I strongly agree with your criticism of this article, but that is pretty clear. And Twitter does freely and clearly acknowledge that a "determined attacker" can snag the secrets from a given app. But they still want to have it both ways. They counsel obfuscation (even though an attacker will observe your secret without bothering to understand your obfuscation method; time spent on "best effort" here is clearly time wasted). They counsel doing things like "using the API through a homebrew proxy that actually holds the keys", which they immediately hedge by stating that they are "not actually recommending these avenues"... http://groups.google.com/group/twitter-development-talk/msg/...
In the end, their "not actually recommended" path of pushing everything through a key-bearing proxy sure looks like the only way to develop desktop and mobile Twitter apps without taking a risk that the following chain of events will occur (and, as someone mentioned, maybe even be set into motion by a competitor): key disclosure, key revocation, app breakage, scrambling to get updates out, unhappy users + lost revenue, etc.
As you say, the problem of "how can we shut off malicious clients" is orthogonal to OAuth. But Twitter is choosing to involve a part of OAuth that is easily compromised in desktop/mobile contexts in solving that problem anyways.
