I disagree. I'm an old enough programmer (in my 40s), I started my career working with proprietary binary formats, and I remember the good reasons why binary formats were abandoned. Where I work, the older someone is, the less likely they are to favor binary formats for structured data (this argument has come up a lot recently).
I'll repeat one or two of the arguments in favor of not using proprietary binary formats.
If you wish to save space, conserve bandwidth, etc, then binary formats are not a good way of accomplishing that. The best way of saving space and conserving bandwidth is to use compression, not a custom binary format! Binary formats are still very large compared to compressed xml, because binary formats still have uncompressed strings, ints with leading zeroes, repeating ints, and so on. If you wish to save space or conserve bandwidth, then you ought to use compression.
If you use compression, though, then using a binary format also, gains you nothing. Binary formats do not compress down any further than human-readable formats that encode the same information. You won't gain even a few extra bytes on average by using a binary format before compressing. It gains nothing to use a custom binary format if you compress, which you should do if you're concerned about space or bandwidth.
Of course, compressed formats are binary formats. However, the compression formats you will use, are extremely common, are easily identified from a text identifier at the beginning of the file, and have widespread decompressors available on almost all platforms. Gzip, Bzip2, and zip are installed by default on the macbook pro I got from work. They're almost everywhere. That is not the case for a custom binary format which you create. Also, compression can be turned on and off. If you wish to sniff packets for debugging, you can turn compression off for awhile.
Here's a different way of putting it. You can think of common compression algorithms (such as bzip2) as mechanisms for converting your files into the most compact binary representation available with no programming effort from you. It does not help those algorithms if you also try to do binary encoding yourself beforehand.
There are a few weird exceptions where it's best to use binary formats. There are small embedded devices which lack the hardware to perform compression. Also, http/2.0 might be an exception, because the data transmitted is less than 100 bytes usually, so adaptive compression wouldn't work well, and it wouldn't be possible to compress across http requests because Http is (in theory) a stateless protocol.
Now though, even private internal saved state never seen by a human is done in XML for bizarre reasons.
There are reasons other than human-readability to use XML. Using xml means you gain an ecosystem of tools: all kinds of parsers, generators, code generators, validators, editors, pretty-printers in your IDE, network packet sniffers that can parse and pretty-print it, etc, on a wide variety of platforms. You lose all that if you roll your own binary format, for a gain of nothing if you compress the data in production.
Also, private internal state is seen by a human on rare occasion. What happens if parsing the file fails? Someone will need to look at it.
