You can blame me for those wasted four bytes (or, perhaps, that wasted terabyte in the aggregate).

The original idea was that on big-endian machines, the resulting .odex would be endian-swapped compared to the original .dex, and this field would provide a reasonably-blatant indication. This would probably help with debugging more than anything else (maybe help with security, but not much), because there's no reason anyone would drop a little-endian .odex file on a big-endian machine (or a big-endian one on a little-endian machine).

We wrote (most of?) the code to get the vm working on big-endian systems, but within Google we never shipped any big-endian hardware AFAIK. I have my doubts that anyone ever did.

Even though the bytecode is being executed on a VM, the VM itself has been ported to the architecture, which has a native endianness. Byte order in the dex that matches the host OS's will likely result in a performance gain as the VM can cast more efficiently.

That's true - do you suppose that this flag might be used if an app developer was targeting a specific CPU architecture, then?

I guess it could be argued that if you're that concerned about performance and know your target architecture, that it might be worth going native rather than running on a VM.

This is just a guess, but I think the odex pass on dalvik switches the endianness to the architecture's native.