The WAV format is not mixed-endian; everything that’s actually a number is little-endian.

The fields the diagram in the article marks as “big endian” are ASCII text— four-byte strings with specific content (“RIFF” for the first ChunkID, “WAVE” for the Format, etc.). If you wanted to treat those as integers in your code, you’d need to treat them as big-endian so their byte order doesn’t get reversed, but they’re really four-byte sequences, not numbers.

I've had this come up with composite data formats. If your data formats includes already existing data formats and they do not all agree on an endianness you are basically stuck with being inconsistent about it.

Yeah I was kind of confused about this when I was reading through the spec trying to figure out what went wrong. I wanted to touch on this in the blog post, but I wasn't able to find a good resource explaining the advantage for mixing endianness in a file format.

Obviously not ideal, but it could for instance come up when the file format has one overall endianness but wants to include fragments of data conventionally encoded with the opposite endianness. Trivial example would be a .tar file containing an assortment of other files, but this would also include say embedding network endian data or images within a larger file that contains other data.