The author's point is that if our APIs worked with structured data instead of byte streams, then we wouldn't need to care about the in-memory format. The standard API would do the hard work for us, allowing us to call send(fd, my_struct);
Since there's no standard API (blessed by the OS) and the lowest common denominator is byte streams, we're seeing all these ad-hoc solutions and a hodgepodge of formats and libraries to deal with. That's lots and lots of time and money spent on rather basic stuff.
And that's why I think the author is wrong about this (he is probably right about thinking (more often) about filesystems as databases, but that's somewhat orthogonal).
The approach you're describing only works for POD-style "structured data". Once you start using OOP of almost any type (though not every type), you no longer have ... well, POD that you can move to/from a storage medium. You have objects whose in-memory format IS important and compiler dependent.
There are other concerns too. His WAV example (I write pro-audio software for a living) doesn't even begin to touch on the actual complexities of dealing with substantial quantities of audio (or any other data that cannot reasonably be expected to fit into memory). Nor on the cost of changing the data ... does the entire data set need to be rewritten, or just part of it? How would you know which sections matter? Oh wait, the data fundamentally IS a byte stream, so now you have to treat it like that. If you don't care about performance (or storage overhead, but that's less and less of a concern these days), there are all kinds of ways of hiding these sorts of details. But the moment that performance starts to matter, you need to get back the bytestream level.
And so yes, there's no standard API and yes the lowest common denominator is byte streams ... because the __only__ common denominator is byte streams. Thinking about this any other way is a repeat of a somewhat typical geek dream that the world (or a representation of the world or part of it) can be completely ordered and part of a universal system.
Of course it can be streamed! Nobody ever suggested it could not be. The point is that to stream it portably (i.e. without knowing the hardware characteristics - and possibly software characteristics too - of the reciever) you have to first serialize it and then deserialize it, because the in-memory representation within the sender is NOT portable.
You're too hung up on in-memory representation. Yes, if it's not right, then it needs to be converted. That can be done for you, or you can do it manually with byte streams like cave man. If you can do it manually fast, then it can be done just as fast automatically based on the declared structure.
It isn't possible to be in a world where the in-memory representation doesn't matter. Someone has to write and maintain that code, and if it's you, then you get the fun task of telling some users their workload won't fit into it. And then they go off and write their own in-memory representation.
Since there's no standard API (blessed by the OS) and the lowest common denominator is byte streams, we're seeing all these ad-hoc solutions and a hodgepodge of formats and libraries to deal with. That's lots and lots of time and money spent on rather basic stuff.