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?
Even so, you're probably right in the long term.
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.
Is it simply that the way they do it now is easier to create/manage?
Seems like a no-brainer.
That's a lot of complexity compared to a simple session-authenticated validation.
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...