Writing data to memory devices
The memory I/O method (serial, parallel) depends on the system requirements the device is intended to meet.

For the purposes of this discussion, I take 'shift register' to be a concept: serial I/O. As a practical matter there aren't memories that use a simple shift registers to implement I/O; instead they implement some sort of serial protocol.

So let's talk about some common memory types and their interfaces.

Small EEPROM intended for occasional data access can make do with I2C, which is one bit serial with a clock. This is the same basic I/O used for chip cards (ISO7816). It's also used for VGA / HDMI 'DDC' information.

NOR flash devices for boot code will typically be SPI (Serial Peripheral Interface) now, which supports from 1 to 4 bits serial (even 8 bits in some cases.) In the past, NOR flash was commonly parallel data with a full address bus before the advent of large memory buffers in SoCs which made loading from a slower device practical.

NAND flash devices are expected to move large data types as driven by applications. NAND has long had a parallel, block-oriented interface, typically 8 bits wide. Specialty NAND for code uses an interface called eMMC, which is 1,4 or 8 bits wide. The familiar SD card uses 4 bits, though internally will use 8 or more bits to talk to the NAND devices.

Finally we come to RAM. This is the very fastest type of memory, and because it needs the very highest speed is typically parallel. DRAM DIMMs have wide buses: 64 bits for a DDR3 module for example.

Besides memories, you have different types of system connections. One basic problem is getting data from one part of a system to another, or from system to system. Doing this with parallel data takes a lot of wires, so this limits performance and makes systems bulkier than they need to be.

Enter SERDES (serializer / deserializer) technology. With SERDES you use a more complicated mixed-signal block to send serial data at very high rates down a single wire. SERDES makes those lazy wires 'earn their keep', maximizing their information carrying capacity. SERDES also solves certain system timing problems as it is self-clocking.

SERDES shows up everywhere there is data to be sent, and the march toward its use is relentless. Some examples:


PCI (parallel) to PCI Express (serial);
SDIO to UHS;
eMMC to UFS;
parallel pixel to MIPI CSI / DSI,
practically everything to USB;
IDE to SATA;
SCSI to SAS; 


and so on.

Sometimes you see combinations of methods bridged together. A typical NAND SSD module will use parallel data for the chips themselves, while the host interface will be some high-speed serial interface like USB, SATA or PCI Express (NVMe).

So if SERDES is so great, why doesn't RAM use it too? DDRx RAM I/O does a good job of making use of the wires, at least so far. There has been ongoing work to move DRAM to SERDES, though that seems to have stalled.