I've used email as a transport mechanism for more things than I care to think about. In some cases it was a perfect fit, and in others... no so much.
I build a system that synchronized user data between to organisations. It didn't need to be real time, just a nice feature where a user could change his or her address a the parent organisation and it would later trickle down to other systems.
A second system has handling orders for production of electricity in the Danish power grip. The decentralized power plants had a little as 15 minutes to react. The designers of this system clearly didn't understand email, the assumption was that emails show up in a minute or two, failing to understand that in reality it shows up when, as you say, "It's good and ready".
Email can be a good it for a messaging mechanism, you just need to consider the application. If you need to communicate with a lot of people or system cheaply, and you can afford to lose a message or two, emails fine.
On the other hand, email and ftp is most likely the two most misused protocols ever devised.
That's interesting about the powerplant .. I bet there was a good amount of face palming going on when that was picked up.
Email appealed to me mainly because it explicitly includes identity. The system I was attempting to use it for was an online school data management system that needed to stay in sync with the schools in house data systems. Unfortunately spam filters just kept breaking things, because in the UK many schools have what are know as "managed services" which translates to underpaid keyboard monkeys with no clue running their IT infrastructure.
failing to understand that in reality it shows up when, as you say, "It's good and ready".
That may be the reality for sending e-mail to random people on the internet.
However, when both the sender and the receiver are under your control then you can indeed make assumptions about average latency, delivery guarantees and failure modes.
I.e. an e-mail will normally arrive instantly (sub-second) unless it is relayed through an unknown path or the network-path is down.
Most MTA's were not designed to be used as a backend message-queue - but can still work very well for that when configured accordingly, as they have most of the relevant primitives baked in (durability, error reporting, redundancy, re-sends).
There's nothing wrong with piggybacking SMTP for such jobs as long as you know what you're doing.
I build a system that synchronized user data between to organisations. It didn't need to be real time, just a nice feature where a user could change his or her address a the parent organisation and it would later trickle down to other systems.
A second system has handling orders for production of electricity in the Danish power grip. The decentralized power plants had a little as 15 minutes to react. The designers of this system clearly didn't understand email, the assumption was that emails show up in a minute or two, failing to understand that in reality it shows up when, as you say, "It's good and ready".
Email can be a good it for a messaging mechanism, you just need to consider the application. If you need to communicate with a lot of people or system cheaply, and you can afford to lose a message or two, emails fine.
On the other hand, email and ftp is most likely the two most misused protocols ever devised.