Sending an email to a local post office does just enqueue a request.

When you send an email the sending process does not block until the email is actually delivered to the ultimate destination. It is not clear to me why sending the email is slower or less reliable than the enterprise messaging solutions you propose to substitute.

From an architecture perspective email is asynchronous and distributed. From a deployed based perspective, Unix boxes typically have their own local post office. From a market perspective, email server solutions beat messaging hands down, in terms of being widely deployed, low cost, high volume etc.

When managing long running tasks messaging systems are not well standardized in terms of how to cancel tasks, review current completion level etc. They just don’t scale for this and are not designed for it.

For distributed processing, use a framework like Erlang’s, which has messaging a primitive part of the model. The overhead of enterprise messaging is a poor fit with distributed processing.

As a replacement for polling, just provide the action you want to perform as a web accessible resource, and hit it when the event occurs. If you don’t need a centralized point of failure or latency why have it?

There are occasions when registration for channels, store and forward, distribution etc. make messaging a good fit. However messaging solutions tend to create an expensive and complex bureaucracy in an enterprise environment, which can be avoided by using with web requests. Using a databases, rather than messaging for reliable storage, also comes with a complex bureaucracy but that is one that is likely to already exists. Messaging just creates new problems.