If you're writing a diagram for little endian, you end up with the bytes going right to left, if you have multibyte values, so you may as well read bottom to top, right to left.
Little-endian is fundamentally confusing, because the bits within the bytes still go the "other" way. Best to just keep the diagram oriented to bits-within-bytes order, and make it clear that bytes-within-words are being plopped into memory backwards.
Just like, back when graphics bitplanes were a thing, it was much less confusing if the diagram just showed (virtual) memory interleaved, the way you'd actually have to deal with it as a programmer, rather than showing the "clean" physical-memory diagrams for what ends up on the "even" and "odd" chips.
I have had to work with data that uses little-endian for bit order as well (although we call it "least significant nit first", and reserve the word "endian" to describe byte order).
We actually dealt with this by adding support to a general purpose open source parsing tool we maintain [0]; where we had to add a feature to the standard specifically to accommodate this [1].
Even though least-significant-bit-first makes sense with littleEndian actually working with it is a giant pain, because approximately no tooling actually thinks that way.
The bits within the bytes have no order because they are not addressable on most hardware. You can imagine them going whichever way you like, even in a different dimension. On an architecture without bit pointers, a byte is a number from 0 to 255, not a sequence of bits.
(x86 does indeed have the bt family of instructions that sort of address bits. I would argue that the existence of memory-operand bit accessors like this that accept larger-than-bits-per-word offsets is bizarre, but the instructions are not backwards. On a big endian system, these instructions would have different behavior depending on word size, which would be odd.)
Bits within bytes have a defined order when you do things like pushing the CPU flags register to memory, reading it back into a numerical register, and then bit-shifting/rotating through it. That's something you can do on basically any architecture that supports preemptive scheduling; there's usually either a PUSHF or PUSHALL there to assist.
But, even without the ability to address the memory at the bit level, bits-within-bytes ordering still matters on any architecture where bits are striped between memory channels, RAID-0 wise. (Just like those graphics bitplanes!) The processor being LSB-first vs. MSB-first on how it interprets the data bus, determines which sockets you put the LoROM and HiROM firmware chips into your Apple II :)
I think it makes a difference when you've got bit packed fields. For example a 32-bit word with a 16-bit field a 4-bit field and a 12-bit field.
If you want that 12-bit value to work nice, it's probably going to be all the bits of byte 0 and the lower half of byte 1. (Or the upper half of byte 0 and all of byte 1). That looks best if you write bits and bytes right to left from zero. That 12-bit value uses bits 0-11 and you can mask it from your 32-bit read with 0xfff. The 4-bit value you can mask with 0xf00 and then shift (or shift first, whatever)
