>> Immediately after each struct are a series of "fix-ups" or "field population instructions" that are basically a sequence of (field number, data type, data length, data) tuples.
Without fixed offsets, you'll have to pay for deserializing everything up front. With Cap'n Proto, you only pay for what you use. In something like what you describe, you'll have to hydrate a bunch of objects, which requires twice as much effort: the reads/writes from/to the buffer, and the reads/writes to the fields of your objects/structs/whatever your language decides to call them. With Cap'n Proto, the generated code directly read/writes from/to the buffer - half as much IO.
>> Basically if a programming language does not use raw struct layout in memory, then it won't be able to take advantage of the Cap'n Proto styled encoding
>> and having a compact wire format is probably better.
What you describe would actually require more data on the wire - you include type metadata and field number, which Cap'n Proto does not. After packing (https://capnproto.org/encoding.html#packing), Cap'n Proto messages will be much, much smaller.