It's basically a format that lets you transmit data somewhat more extensibly than JSON would on its own (and doesn't take a huge performance hit).
This means that you can for example, transmit an array of dates and not need to worry about parsing the dates in the right location when you receive them.
Additionally, it's extensible, so you can define formats for any domain specific data that you're dealing with, if you need to.
Manually marshalling/unmarshalling JSON has been a pain point for me on recent projects. I took a quick look at Protocol buffers just now and instantly understood how that will solve most of my issues with JSON. I define a simple message format (.proto) and generate native classes. My service methods can use the generated classes as parameters.
The only thing missing for me was native support for JS (but I quickly found 3rd party libraries).
I don't quite understand how transit, since it's schema-less, addresses that problem. From transit-java docs:
Object data = reader.read();
I might be missing something, but it seems I have to manually create the native classes on both endpoints and cast to those classes. Either that or I still have to manually extract values using the reader API.
This means that you can for example, transmit an array of dates and not need to worry about parsing the dates in the right location when you receive them.
Additionally, it's extensible, so you can define formats for any domain specific data that you're dealing with, if you need to.