Fair enough I guess, though in that case my mind goes to just having the recipient queue its own tasks internally and respond immediately, if the sender doesn't want to wait on it to finish

Sure you can do that, but I'd say in the general case "it depends".

If your needs are fairly basic, that's probably the best approach. You also eliminate some overhead (piping messages through a middle man, operating said middle man, etc.).

But it's my understanding that if your needs are a bit more involved, the complexities of building a solid queue mean that it'll take time away from building your actual product. In that case, you may be better served by an off-the-shelf solution which already handles the corner cases and is good to go.

I think this is the usual decision between using an external product and rolling your own.

If there are multiple recipients then they may need to each maintain their own queues. But these queues may implicitly have an expectation of being in sync with each other. If you use a centralized message queue then there will be a single source of truth about what messages were received and in what order. This can help to avoid or debug problems that can arise if sender fails to send request to some receivers or if some receivers fail to process requests.

Which we know from the article that the recipient in this case was ALREADY doing. They were using RabbitMQ as a glorified cron job to poll the "status" of the other service every 5 minutes.