We have a IBM MQ v8 setup setup with 1 high volume non-persistent queue and many consumers (50+) on that queue. The large number of consumers is needed to be able to process
MQ's default behaviour is to give messages to the MOST RECENT getter. That generally improves performance as that process is most likely to be "hot" (in the processor cache). So you should not expect equal distribution of messages. If you are seeing one application getting most messages that implies that it is regularly getting through processing one message before another is available for retrieval. It is rejoining the queue of waiters before the next message is available.
There are many aspects that affect overall performance including transactionality, retrieval criteria, contention etc so it's not really possible to say what your problem is, or whether changing that default distribution algorithm (there is an undocumented tuning parm that reverses the queue of waiters) would help. And having client connections where the waiting is really being done by the "proxy" svrconn processes and threads makes it more complicated.