Although they can all work together, I find it easiest to look at events and listeners together, and then tasks and queues together.
Events and listeners
Events are objects that store data that is “fired”, the Laravel event system “catches” an event object when it starts, and then all listeners registered for that particular event are started.
If you think about it, this is similar to how exceptions work. You throw an exception, and you can define several catch blocks to respond depending on which exception is thrown. In the case of events and listeners, an event occurs, and one or more listeners represent the contents of the catch block. Although the likes of Events and Listeners are not error handlers, they just have conceptual similarities.
Jobs and Queues
I think the best way to think about it is like a line in a bank. The row itself is a queue, and each client in the row is a Job.
To process jobs in the queue, you need command line processes or daemons. Think of starting a queue daemon on the command line as adding a new bank counter to the pool of available bank counters. When the daemon is available, it will request a sequence for the next job, for example, a bank counter asking the next person in the line to go to the window.
Each person in the queue has a specific task that they want to perform, for example, making a deposit or withdrawing funds. The action that the person in the queue must perform is Worker in Laravel.
The worker is what the demon will do for the task that was taken from the queue, just like the task is what the bank client does for the client who stepped forward from the line.
Hope any of them make sense.