As nice as Message Pack might be, 'The best way of serialization' I'm not sure is a very helpful statement. It can't be 'the best' because 'the best' depends on the specifics of what you are doing. As noted in the OP: "...its pros and cons should be carefully considered, and there are many situations where it simply does not offer enough advantage...".
I, for instance, am still using the much-less-cool yaml, because I need to reference the same object at multiple points within the same serialization. JSON and (AFAIK) msgpack just dont do that, so in this case there is simply no argument. It took me far too much playing around to figure this out, because the internet is full of "JSON > yaml" and similar broad statements, and very few plain descriptions of what the actual different use cases for each type of serialization might be.
"Best" is a subjective value judgement here. Difference scenarios call for different strategies.
Once upon a time, I had to write a serializer that was expected to be run hundreds or thousands of times a second, once for every request in an AJAX app. The solution I chose was to not serialize at all; always keep the data in a binary blob (a byte array) and write a facade of ephemeral objects on top of it, essentially containing nothing more than their offsets into the blob. Because the ratio of read/write operations to serialization operations was so low, this made a lot more sense than building an object graph, only to throw it away a millisecond or two later.
I, for instance, am still using the much-less-cool yaml, because I need to reference the same object at multiple points within the same serialization. JSON and (AFAIK) msgpack just dont do that, so in this case there is simply no argument. It took me far too much playing around to figure this out, because the internet is full of "JSON > yaml" and similar broad statements, and very few plain descriptions of what the actual different use cases for each type of serialization might be.