How about this way: The decimal number 19088743 is stored in a 32-bit memory word on a big-endian machine. When asked what the four consecutive bytes are, from low address to high, the debugger displays "0x01, 0x23, 0x45, 0x67".
Now, let's put that same decimal number into a 32-bit memory word on a little-endian machine. When asked what the four consecutive bytes are, why does the debugger not display "0x76, 0x54, 0x32, 0x10"? That's what would happen on a truly little-endian hardware system, as used by little-endian human thinkers, expecting a little-endian human display convention. Instead, it displays the weird hybrid "0x67, 0x45, 0x23, 0x01" version. Why aren't the humans who like little-endian not bothered by the fact that the human convention is not completely little-endian, and shows the two hex digits within each byte with a big-endian human display convention?
Or, how about this: We all agree that decimal numbers as currently written by humans follow big-endian conventions. Certainly someone could come along and claim that they preferred little-endian representation for decimal numbers, so that one thousand two hundred thirty four should be shown as 4321 rather than 1234. Great; good luck to them. But if they said that they're actually going to write it as 3412, I hope we'd agree that they weren't really following little-endian conventions for displaying values for human consumption.
So, yeah, I'm complaining that the current widely accepted human convention for little-endian display is not self-consistent and not fully little-endian. And, you're right, it has nothing to do with the actual hardware, which doesn't care how we display stuff.