In an ideal system (read: well programmed), specific is more efficient than generic, but generic is more broadly applicable. You save development time using generic, you save user time using specific.
A good example would be images. If you used TCP's gzip compression on a bitmap, which has no built in compression, you are applying a purely generic solution. It will look for patterns that it can replicate in less data. For example, 1000 pixels of pure white could be changed from 3000 0xFF bytes into a few bytes, such as an instruction of "replicate bytes" followed by the count "3000" and the value "0xFF". (gzip is way more complicated than that, but you get the gist) But it won't notice that a 100x1000 rectangle of white could be replaced with a single instruction; it'll need 100 instructions, each time it reaches that 3000 block of 0xFF in the stream.
On the other hand, if you use a JPG, which has built in compression, it knows it's an image. It can recognize those regular blocks, it knows that it can skimp in certain areas and the human eye won't notice the difference. If a few pixels are slightly off color, people won't notice, but the machine can fit it into a pattern that makes it more compressed.
But if you tried to apply that compression to binary data, it'll corrupt it.
Alternatively, if you used a lossless image compression type, like say, PNG, it'll have all of that image theory behind it to recognize the ways that it can reduce image size. While you could apply this to regular data without corruption, it would be significantly less useful due to the patterns it's looking for being all wrong for the patterns in the data.
Gzipping on top of that can also find patterns in the patterns to make it even smaller.
The main advantage that MessagePack seems to have over gzip (from a cursory look) is that it eliminates the closing elements (ie, the closing quote, the closing brackets, the commas), cutting the syntactic overhead of json in half, at the cost of making it less readable and human editable. Gzip can't do that.
It doesn't appear to compress the actual data, which gzip is good at, so you should use the two compressions to complement each other. Gzip in TCP on top of MessagePack in application.
However, there is the possibility (I don't know, you'll have to test it) that gzip could handle the patterns in regular json better than the patterns produced by MessagePack, and so could produce a smaller size. I find that doubtful, though, as gzip is more intended for general binary than text specifically.