You can label the access key "IMAP key," but that's just the human readable label. There is no functionality tying a key to particular Google services; any key unlocks them all. There should be such functionality, which was one of the points made in this (admittedly flawed) article.
For the record, you are right when you say they don't "own" you account, since they can't change the password. But they do have broad access.
I just think people should be clear on what the keys can and cannot protect you against. You mentioned revocation -- one thing that will motivate people to do timely revokes is being aware of the potential harm of leaving these keys active after they are compromised. From what I recall of Google's setup process, they don't prominently tell people to be sure to revoke their keys in certain situations, e.g. you lose your iPhone, you lose your iPad, you lose your laptop, etc. It's easy to get the impression while activating 2-factor auth that these keys are more limited than they are and that you don't have to worry too much about them.
OK, I guess it would be an improvement to record the first-used service and lock it down only to that. Still, with the old model grabbing the password still gave you access to all services; this is definitely not a degradation of security from before.
""" Please use your account password instead of an application-specific password. """
And obviously it will then prompt for your OTOP. Again, this is absolutely no worse than someone getting your Google Account password anyway... and even if they do, they can only use it for select things that are allowed to be used via one-time-use passwords - it's just that we happen to be discussing email and IMAP is a rather large exception. Presumably this isn't the case for other Google services.
(Uh, guys, did you have a different experience or something?)
(I'm not the one who downvoted you, by the way, so I can only guess at why.)
The one thing I will grant the author is that the explanation given for application-specific passwords could be somewhat clearer.
Feel free to call me stupid, but the first time I used the interface after reading the description, I remember not fully understanding what was going on and thinking that I had to choose a particular name to use a password with a particular application. It took me a little more thought about the purpose of these application-specific passwords to understand that that wouldn't make any sense, and these are instead just plain old passwords with labels for personal convenience in case you want to revoke a particular one later.
I like to think of myself as reasonably technically inclined and this still threw me off, so I can certainly imagine how it would really confuse an average user (though the number of average users using this feature is probably pretty negligible).
I am not sure about that at all. For imap for example you could be required to submit your password followed by one time code in single login command:
. login youraccount yourpasswordyourotp
So in the password prompt when the client connects you should type in your password + your otp in one step. But that is still two factor authentication. Of course there is no sense in caching/storing such password. It would be less convenient for sure but saying that you can't do 2-factor for imap is exaggeration.