It probably doesn't hurt that computers make it easier to go left to right.
That's not actually true for all platforms. I programed 8-bit computers in Assembly, so I know a thing or two about this.
Some architectures back in those days, had character mapped graphic modes, where instead of assigning color to every individual pixel, the programer could map 256 8x8 characters, using 2 colors on each, then write them on the screen as strings. That was super efficient, since it only took 24 lines of 32 character to copy to the video memory. Scrolling to the left was done by moving the character then masking the new address on that line with &1F, if the result was zero, the character would be out of the screen and would be discarded, then a new one was placed position zero. To scroll on the other direction, each character was moved left and if it's new address underflowed (I.e. became less than zero), it'd be discarded, then a new one was placed on the right. Both are equally easy to do.
But in these kind of architecture, it was much easier to make vertical scrolling games. In side scrolling, you have to worry about the offset between one line ant the other. A level 8 screen wide would require 24 strings of 256 characters, and each time the visible window had to scroll, the code would have to read 24 bytes, each 256 bytes apart on the memory, or have the level set as 256 columns, then read a column and place the 24 bytes in the video memory, each 32 bytes apart.
Vertical scrollers were much more trivial, move every byte from the second line forward to an address 32 bytes lower, then add a string on the last line. Done.
Of course, this relied heavily on the hardware's architecture. I never coded to Nintendo's 8-bit architectures, so maybe THEIR particular hardware was more friendly to side scrollers that moved to the right.
That's not actually true for all platforms. I programed 8-bit computers in Assembly, so I know a thing or two about this.
Some architectures back in those days, had character mapped graphic modes, where instead of assigning color to every individual pixel, the programer could map 256 8x8 characters, using 2 colors on each, then write them on the screen as strings. That was super efficient, since it only took 24 lines of 32 character to copy to the video memory. Scrolling to the left was done by moving the character then masking the new address on that line with &1F, if the result was zero, the character would be out of the screen and would be discarded, then a new one was placed position zero. To scroll on the other direction, each character was moved left and if it's new address underflowed (I.e. became less than zero), it'd be discarded, then a new one was placed on the right. Both are equally easy to do.
But in these kind of architecture, it was much easier to make vertical scrolling games. In side scrolling, you have to worry about the offset between one line ant the other. A level 8 screen wide would require 24 strings of 256 characters, and each time the visible window had to scroll, the code would have to read 24 bytes, each 256 bytes apart on the memory, or have the level set as 256 columns, then read a column and place the 24 bytes in the video memory, each 32 bytes apart.
Vertical scrollers were much more trivial, move every byte from the second line forward to an address 32 bytes lower, then add a string on the last line. Done.
Of course, this relied heavily on the hardware's architecture. I never coded to Nintendo's 8-bit architectures, so maybe THEIR particular hardware was more friendly to side scrollers that moved to the right.