I felt this was one of the few ways you could insure the game could still be played in perpetuity after a company had gone away and their servers shut down, without requiring people to host a dedicated server.
Obviously this wouldn't work with real time games, and players could potentially abuse the data being sent if you're not careful and/or don't encrypt the data, but I prefer making turn-based games anyway.
Having worked for several small companies that have shut down, that's a concern to me (although you can't even download most of those games anymore since they were taken off their respective app stores).
I found it interesting Microsoft Garage made an "IM client" that uses email in the backend recently. In some cases, I think all these new protocols we invented was reinventing the wheel, when we already had something that worked fine.
Using it for games is a really neat idea. In a plaintext format, you could even space out things like a Scrabble board, using @ and & symbols for special blanks or such, and one user could be lower case letters, and the other could use capital letters. Dots for normal blanks.
I love simple formats.
For example take a look at the RFC 5322 and try to determine what is or isn't a valid address. You have a lot of weird edge cases to take in account and it's not always obvious how you are supposed to handle them.
However, if you are building a piece of software that simply communicates over email, you only have to support a relatively straightforward format for email that everyone else inherently supports.
Depending on the platform you're building on, a lot of the basics of actual email sending and receiving may be handled by the platform directly as well. I didn't have to write the SMTP handling for my code, for example, because the platform I was building my app on pretty much did it for me.
Also, the great thing about figuring out weird edge cases with email, is that email is such a widely used and universal protocol, there are literally millions of places on the Internet that have code for it or talk about it. There's a lot of resources out there.
Since the game would need your email password in order to load incoming messages I would advise them to create a new email just for game communication purposes anyway, and tell them not to use certain characters if for some reason I couldn't get them to work (although the libraries should be able to handle it anyway).
I have to strongly disagree with that, it might be easy to spot good UI but it is not normally easy to make a good UI.
As for SMS Twilio is dirt cheap $0.0075/message + $1/mo for a number also combining it with something like Wit.ai [0] to parse your text and you can get pretty far.
And I thought of email. A well standardized message queuing platform that could easily implement a basic text command interface. So I ended up with a rudimentary chat bot. (I could've done SMS, but didn't want to find and pay for a service for that.)
And a few weeks before this announcement, I'd been thinking about how to handle queries to my chat bot my software didn't understand, and I was thinking "Hey, I wonder if I could have my bot ask Cortana stuff if it doesn't know". And Microsoft's picked up and really ran with this model with Bot Framework.
Obviously they've been working on this behind the scenes for a while, I'm not trying to take credit for the concept by any stretch, but I thought it was funny that I had been thinking along those lines myself before I heard about this.
Good UI isn't hard. Generally, it's simple and universally understood. I instantly understood where Microsoft was going here because I had the same thoughts. That being said, I want my system running mostly locally/self-hosted, so an Azure-based platform like Bot Framework probably won't work for my own system, though I might very well send requests to other bots using it.