Queues vs Explicit Background Threads in Microservices

A company has a microservice architecture that uses queues to asynchronously process requests. Service A sends a request directly to service B, service B puts the message on a queue on an external queue server and responds immediately to service A with a 202, got your request, thanks, we're working it, so that the request/response terminates and service A can go about other business. Service B's MessageListener immediately receives the message from the queue in a new thread and processes it in that thread. This nicely decouples the services.

Is there an advantage to using a queue like this over explicitly spawning a background thread? I can see that if the service went down during the infinitesimal time when the queue has the message, the message would stay on the queue and not get lost, the queue would retry sending, and the service could continue processing as soon as it came back up as if nothing had happened. But since service B both puts the message on the queue and pops it off, this time is so short it seems to be of little use. The added dependency on an external service seems unnecessary.