This seems like a good final check to make to stop the non-null ReplyTo object from causing the wrong value to be returned, but it doesn't seem to me that it fixes the real underlying issue: why does the client have a non-null ReplyTo object, i.e think there was a reply-to set when there wasn't?
I think its worth looking into that, as it implies either an issue further down inside the transport code, that the client is actually sending the wrong information to the broker originally, or the broker is sending the wrong information back to the client. Identifying which of these it is and rectifying that might even allow for resolving this issue for older version clients when they are interacting with the newer clients/brokers, rather than confining the workaround to only consumers using the new client.
(P.S. was there a reason not to use the original JIRA with Pavel's patch attached to it? Or to not fully update either one after the commit?)