While I somewhat agree with you, it's not as though these problems didn't already exist with IMAP. I think a better way of looking at it is this is the first step in removing the password from 3rd party access. Maybe at some point in the future they'll add more fine-grained access, but for now removing the credentials from the process seems like a good first step.
Not sure why they really need an API though. Seems to me like it would have been a better solution to stick to the IMAP protocol and allow an alternative method of authorization. For example an application would request access to your email, then they'd get an access token and use that to authenticate with IMAP. They could then try to delete an email with the IMAP protocol and if they hadn't requested that scope they're receive an error.
HTTPifying everything seems to be a trend, not sure what the real purpose is - if anything it's just making things less open.
I think accessibility. More developers are comfortable with REST than they are with IMAP.
In fact, at least the connotations I have with IMAP/SMTP: "shit still gotta learn that before I can start". Even though it would probably not even take a couple hours to get started.
Not sure why they really need an API though. Seems to me like it would have been a better solution to stick to the IMAP protocol and allow an alternative method of authorization. For example an application would request access to your email, then they'd get an access token and use that to authenticate with IMAP. They could then try to delete an email with the IMAP protocol and if they hadn't requested that scope they're receive an error.
HTTPifying everything seems to be a trend, not sure what the real purpose is - if anything it's just making things less open.