If you are just using MQ so that one application can store messages on a queue for another application to retrieve, all within a single queue manager then a local queue suffices. Within MQ messages always reside on local queues (normal or transmission queues), and the other definitions just help route traffic.
An example of when you would use a remote queue is when you wish to split the applications apart, so the putter application puts to one queue manager on one machine, and the consumer/getter application lives on another queue manager potentially on another machine. In this scenario the putter can address a remote queue, but the messages really end up on a transmission queue - then a channel retrieves the messages from the transmission queue, flows it over the channel to the other queue manager and puts to the 'local' queue on the destination queue manager which the consumer is reading from.
Using a remote queue for example, it is possible to split apart the producer and the consumer without needing them to change the queue name they get from - Imagine they both the producer and consumer read from queue MYQUEUE. You could then move the consumer to one queue manager (QM1) with a remote queue called MYQUEUE whose real (remote) name is MYQUEUE on another queue manager (QM2). On queue manager 2, you would then have a local queue definition called MYQUEUE. The producer still opens and writes to MYQUEUE and doesnt know its messages will be routed, and the consumer still reads from MYQUEUE and retrieves the messages.
