Procedural programming can be modular too (functions, libraries, etc.).
systemd is not only modular in that sense but also in the sense that the
Linux kernel is modular, i.e., you can easily activate/deactivate parts of it
at compilation time:
https://freedesktop.org/wiki/Software/systemd/MinimalBuilds/
... and it is also modular in the sense many different "programs that do one
thing and do it well" (as Doug Mcllroy wrote)! According to
http://0pointer.de/blog/projects/the-biggest-myths.html :
If you build systemd with all configuration options enabled you will build 69
individual binaries. These binaries all serve different tasks, and are neatly
separated for a number of reasons. For example, we designed systemd with
security in mind, hence most daemons run at minimal privileges (using kernel
capabilities, for example) and are responsible for very specific tasks only,
to minimize their security surface and impact. Also, systemd parallelizes the
boot more than any prior solution. This parallelization happens by running
more processes in parallel. Thus it is essential that systemd is nicely split
up into many binaries and thus processes. In fact, many of these binaries are
separated out so nicely, that they are very useful outside of systemd, too.
These binaries are under the systemd umbrella and not independent projects.
They include the same libraries (fix a bug in it and you fixed it for *all*
binaries), they are thought to work together, they expect similar arguments
from the user, etc.
