Also reminds me of the huge shortcoming that these "simple" serialization libraries have. In most use-cases you're eventually going to need some way to add/remove fields from the payloads.
JSON and protobuf make that easy. You can start emitting the new field and then update the receiving end at your leisure.
With these libraries you have to write your own versioning system. For a small performance improvement over JSON parsing it's pretty much not worth it. There's almost always going to be a piece of lower hanging fruit.
This is a valid concern, but it's possible to work around in a similar way that you do with protobufs: never redefine the format of any message type used in production, but instead, introduce a new message type whenever you need to change the format.
For example, imagine you are sending message type 1 with format "%d %d" and later you realize you actually need three instead of two ints. You introduce message type 2 with format "%d %d %d" and update your readers to support both types. Once those are deployed in production, you update your writers to send the new message.
This is kind of the opposite of what happens with protobufs, where unsupported fields are silently dropped by the receiver, so you can update the sender before the receiver. But this is arguable less safe, since if the receiver drops some fields, it might not interpret it the way the sender intended. In that case, it might be more sane if the receiver outright refuses to process a message it doesn't understand.
JSON and protobuf make that easy. You can start emitting the new field and then update the receiving end at your leisure.
With these libraries you have to write your own versioning system. For a small performance improvement over JSON parsing it's pretty much not worth it. There's almost always going to be a piece of lower hanging fruit.