Pipeline intercommunication aside, most large programs of any quality *are* formed from a bunch of small "do one thing well" utilities. They're commonly called "libraries".
Hit it dead on.
People don't want the added work of making things work. It's like building a floor: you need to strip off the old finish, reenforce the subfloor, ensure the floor is level, pour thinset, roll ditra, pour more thinset, lay tile, clean, and grout. Some folks leave old linoleum or hardwood flooring, claiming it's stable, and then pour self-leveling compound or just screw down concrete board, then put tiles on top. Some just cement tile straight to the floor, or pour SLC and cement the tile to that.
A properly built tile floor has many interfacing components. Tiles don't delaminate due to deflection or material expansion. Expansion joints at walls and proper intervals prevent buckling and delamination or cracking. The floor holds heavy appliances and large live loads, handles vibrations, and even impact. By contrast, a poorly-built tile floor tends to delaminate when temperature or humidity change a few percent repeatedly over 2-3 years, or crack tiles, or have grout rapidly decay from deflection and vapor infiltration.
Modern Web browsers isolate plug-ins and separate rendering threads (tabs) in separate processes with IPC. A runaway page still freezes the entire Chrome browser until something kills it; a crash in a plug-in or page doesn't bring down anything else. Isolate contexts allow security context changes: a simple render process can drop all access outside of specific system calls (openGL, etc.), actions on open file handles at current access (i.e. open for read, read-only--allows for giving ownership of a network socket to a process), and IPC to the parent (through sockets, pipes, shared memory, and so on); most of this falls under system calls to affect open file handles (i.e. an OpenGL object, an open file, an open pipe or socket).
It would make sense to have an init system, like SystemD. It would make sense for SystemD to provide an init like SysVInit: a simple, small, very basic program to read the init configuration and start the system. It would make sense for the init process to start first an init manager that resolves dependencies and tracks running start-up daemons, which examines the system on initialization and starts the mount point manager if not started (to ensure the temporary and runtime directories are mounted), and then begins bringing up other init system components, hardware managers (udevd), and so on, as per the configuration of the init system.
It doesn't need to be a giant monolith. It can be a collection of utilities all dependent on each other, running 3 or 5 or 15 services all communicating with each other, all to bring up the system and supply system state management. This is the simplest and easiest way to make a complex system, aside from the overhead of writing a new program from scratch to surround the collection of functions you want to use. You'd have to put the IPC stuff into a library, and work out how each program communicates with its dependents and dependencies and how it reacts when they're not around. Each task, however, acts as a readily-verifiable utility or daemon, and so does not interfere with understanding of any other task by mixing their code together.