Except that it's often convenient for encodings to sort lexographically and numerically the same way. There are several multi-precision number formats with this property, but they're all either equally slow to load on any endian machine, or faster to load on big-endian machines.
Also, on a 64-bit big-endian architecture, you don't need specialized string comparison instructions to get efficient string comparisons. The code is only slightly more complicated on BE architectures that only support aligned 64-bit loads.
>Little-endian also feels more natural for big integers: the byte at offset x has weight 256^x.
This is literally the opposite of how most programmers in the world write numbers naturally.
See "1234". The digit at offset x from the right has weight 10^x. That corresponds to big-endian.
Considering that the only important difference between little and big endian is when people have to read or write it by hand, we should probably model it after common human representation...
By the way, this "natural" way of writing numbers comes unchanged from right-to-left writing system of Arabic. They naturally read 1234 starting from the lowest significant digit (here, '4').
I'm not sure about Arabic, but my understanding of Hebrew (another member of the Semitic language family) is that they still pronounce the numbers left to right, and if a line break forces digits to be split across lines, the most significant digits are put on the top line.
You got me curious. I googled and found[1] that indeed they only pronounce numbers 21-99 that way, e.g. for 31 the order of words is "one thirty", but higher order components go left to right, e.g. for 25031 the order of words is "five twenty thousand one thirty".
Contrast with a big-endian representation, where the byte at offset x would have weight 256^(length - 1 - x).