You're right in that better protocols can be swapped out in this design pattern and that's fine; most decent external service consuming code does this so it makes sense in that regard.
But where I'm not convinced is in the API itself along with the location in which we are abstracting IMAP and POP at. The abstraction you could recreate most of what this service does with a language library so I don't really get why making it a service is even needed in the first place especially with so many worried about storing their data elsewhere. The API has limited ability to do push (webhooks are only good for web applications not thick or mobile applications) and I didn't really see how they're handling the dual authentication required.
But as I said I didn't want to just poopoo the idea; I'm curious as to where it goes but with version 1 I don't see what usefulness it gives me as a developer.
Still I would love to see people plug other protocols in. I guess that was your point. Making everything fit in the REST paradigm is anything but progress in my humble opinion.