I'm sorry I can't help you with your specific question, but I have a suggestion to offer.
I'm just starting to look into MQTT, to be used with a Yun. My plan is to do as much of the network and heavy processing coding, including the MQTT communications, on the Linux side, probably using Mosquito for OpenWRT.
I don't plan on using any publish/subscribe library in the sketch itself. My experience using any of the YunServer/YunClient/HttpClient/FileIO/etc parts of the Bridge Library tells me that while it is a quick and easy way to get that functionality going without doing any Linux programming, it's not a particularly efficient or robust way to do it. Linux is much more adept at handling that sort of thing directly. I see no reason why the PubSub library running over any type of BridgeClient socket should be any different.
The issue is that when you use a Bridge Library client to control your network connections, you are still really managing them on the Linux side. However, you are incurring a lot of overhead communicating over the serial port that is between the sketch processor and the Linux processor. That communications is relatively slow, and the code takes up precious limited code space in the sketch. If the network connection is really being handled on the Linux side, why not do all of the control there? It will be faster and more reliable.
My personal experience with the Yun has convinced me that the best organization in most cases is to do as much of the application's processing on the Linux side as possible. Especially anything network or file related. The sketch should basically be a dumb I/O processor that reads/writes pins and performs protocols to talk to the devices connected to the shield pins. The sketch communicates to the Linux side using one or more Process objects. I'm a big fan of the Bridge Library's Process class, but not much of a fan of its other features.
Just my personal thoughts on the topic, and how I plan to approach it. Take it for what you will.