You should use a queue wherever you might otherwise experience a bottleneck in your application. A common example is handling image uploads... this can include resizing an image to various standard sizes. This is an example of a compute heavy task, there are similar tasks that may take a lot of memory, time or effort, and can be serialized away. Another example may be a persistent logging system, if you have spikes in activity, and MQ can act as an output buffer.
You have limited resources available for these types of tasks, and you don't want to slow your main service(s) for these types of work. This work can be offloaded efficiently.
Beyond these obvious examples it depends on load. You may want to inject an intermediary service that acts as a caching layer for certain types of requests, and an MQ can allow for distribution of the work (RabbitMQ supports an RPC request type that's VERY useful here).
In the end, it's best to avoid these types of systems as much as possible as they add complexity to the system, which comes at a cost of administrative overhead. Keep things as monolithic and simple as much as possible, and only worry about adding real complexity when it is really needed. Most systems are replaced long before they actually need some of these kinds of patterns in place. You can also scale vertically a LOT before you need such system distribution with modern computers (and even those of the past 5-6 years).