Systems-on-Chips (SoCs) are similar to MCUs, but distinguish themselves from those types of embedded systems by having some level of integration while still requiring a number of external components to function. They are commonly found as part of a single board implementation (Single Board Computer (SBC)), including the PC/104 standard, and more recently form factors such as the Raspberry Pi and derivative boards:
This diagram was used from https://xdevs.com/article/rpi3_oc/. It clearly shows how an SBC (in this case, the Raspberry Pi 3) is laid out. The BCM2837 is the ARM-based SoC, providing the CPU core and basic peripherals (mostly broken out into the header section). All of the RAM is in an external module, as are the Ethernet and Wi-Fi peripherals. ROM is provided in the form of an SD (Flash) card, which also provides storage.
Most SoCs are ARM-based (Cortex-A family), though MIPS is quite common as well. SBCs are commonly used in industrial settings.
Other instances are mass produced boards, such as those for smartphones, which do not form a predefined form factor, but still follow the same pattern of having the SoC and external RAM, ROM, and storage, as well as various peripherals. This is in contrast with the MCUs of the previous section, which would always be able to function by themselves, except for the few requiring an external ROM.
Compared to MCUs, the development challenges of SoCs tend to be far less severe. Some of them are on the level and have an interface where you can even develop directly on the device, even doing compilation cycles on the device without having to do cross-compilation on a PC and copying over the binary. This is also helped by running a full OS instead of developing for the bare hardware.
The obvious disadvantage is that with this increase in features comes an increase in complexity, and the resulting complications, such as having to deal with user accounts, setting permissions, managing device drivers, and so on.