I said it then, I'll say it again -- The solution is obvious: allow per-password permissions.
For instance, if I make an app-specific password to sync my bookmarks, that password shouldn't provide access to my Gmail or my settings. Why isn't this already a feature?
This might be difficult to administer. Nobody smart stores users' passwords directly, so it's not like they can list different passwords with their associated permissions on a page. If you go with user-selected "nicknames", then do you require the app to use the nickname too? Or do you just compare with all the hashes on the user's account? Maybe instead the app has to pass a hash of the perms themselves, serialized in some canonical way. How many users can figure this out? I've known DBAs who couldn't figure out analogous situations.
Google already requires that you name each ASP and provides a table listing the name, the date it was created, the date it was last used to log in, and a link to revoke it.
They'd just need to add an option to modify those. The OAuth entries on the same page list each's entitlements, though you don't have the option to modify them.
The AWS Identity and Access Management (IAM) system [1] is perhaps the most comprehensive RBAC deployment I've encountered in a web-based service. It's extremely powerful, extremely flexible, and rather hard to use. AWS is a service designed (primarily) for developer-types, so if they roll out something that requires users to have a relatively strong understanding of security concepts (and to expend some thought and effort to get things right), that's arguably OK.
Google is a different story. People commenting on this thread would appreciate some in-depth manual controls over the resources each Google credential can access, but making this sort of thing accessible/understandable to an average user is a formidable challenge.
They might be able to get part of the way there using a something like a TOFU (Trust on First Use) policy - e.g. after you create an ASP and use it to login over XMPP, that ASP would only be usable for XMPP logins for the remainder of its existence. However, this might still confuse some users or break some assumptions here and there (e.g. what if you have a client application that's designed to do both email and chat?)
Besides all this, I wouldn't be surprised if Google would have to do some major backend re-architecting for this sort of thing to even be possible...
Per-password permissions are basically the RBAC design pattern [1], which at it's core requires 3 tables with 2 N:N joins in a relational mapping structure (the wikipedia article lays out 4 classes/tables).
That's a lot of complexity compared to a simple session-authenticated validation.
