Such a thorough and well-reasoned explanation certainly should convince anyone.

Maybe, (and thanks), but the reality is that for many people who have come from Java and other multi-processing backgrounds, my explanation won't necessarily ring true, because it goes against much of what they were taught in colleges; or read in (often highly recommended) books (see the real time section:barriers; latches; exchangers) and on training courses.

There has been -- and still is in many circles -- far too much emphasis placed on synchronisation -- which creates all the bad guys of multiprograminig as listed under "Realtime Anti-Patterns". If you don't synchronise at all, none of the bad guys can happen.

(The difference between someone who’s cooking a hamburger, and the hamburger itself.)

I don't think your burger analogy helps much here. The problem lies not (so much) in work-unit .v. worker, but in how the workers communicate.

The best analogy I have is the difference between old-school voice mail; and those dratted call-center "Your message is in a queue and will be answered shortly - tick-tock -- We're sorry but due to the high volume of calls there are no free agents; please hold" queuing systems.

The problem is not the queue per se, but the synchronicity of that queue from the callers perspective. From the call center's perspective, it is an efficient way of distributing the workload. But from the caller's perspective, having to stand around listening to the typical "Your call is important to us..." lies is just dead, wasted cycles.

On the other hand, voice mail allows me to ask my question and get on with something else until an agent becomes free and calls me back. Ie. It is a (pair of) asynchronous queues.

Of course, the downside of that is the phone tag game. It can happen in bi-directional queuing also.

The solution is promises (also known as futures; also known as deferred synchronicity).