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.

But they could have just as easily said the integer value for "WAVE" was 0x45564157 in LE and been perfectly consistent.

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.

Because the important thing about those fields is that they aren't really big endian at all, they're clearly ASCII characters. Why the spec you have decided to say they were big endian is beyond me.

Because Microsoft.

Well IBM+Microsoft but really... because 90s and x86.

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.