Not only is it modular, the system is fully composable, allowing the admin to build each layer upon each layer to their own liking. The layers are not tightly-coupled, and it's entirely possible to replace any or all of the layers:
When people complain about sysvinit being old and outdated, these claims are usually considering the sysvinit+sysv-rc+initscript triad as a single entity. sysvinit is old, but it's a tool with just two purposes: running specified programs and runlevel switching. You can build anything you want on top of that. It does exactly what it was designed to do, and *only* what it was designed to do. It's not broken, and never was. If you want more functionality, you build that on top of it.
Some parts of the old system were crusty, for example dynamic networking configuration. But the vast majority worked pretty well, and pretty efficiently. And it would have been perfectly possible to fix those issues, with vastly less effort and disruption than throwing it all away and breaking much backward compatibility in the name of inter-distribution uniformity (and consequent stagnation).
Note that while common distributions came with their default, it was absolutely possible to run with all sorts of different combinations of components; Debian supported several. file-rc was a supported alternative to sysv-rc, and daemontools and other alternatives were also available. It's this very flexibility which allowed systemd to be swapped in relatively easily. But consider that once systemd was adopted, the vast majority of this flexibility was lost. The low-level init, the rc runner and the initscripts are all in one place, and it's no longer possible to swap one part for another or tweak one little bit. It's all or nothing, and that will effectively entrench it. As an ex-Debian sysvinit/sysv-rc/initscripts maintainer, I wasn't dictating that you use them all together. You want to use openrc, or daemontools or s6? Go for it, you don't need me to approve it, you do what you like. Want to change the initscripts around to do something different, be my guest. We took care not to break any custom setups on upgrade as well, e.g. preserving file-rc configuration when adding/removing/upgrading packages, as well as helper script API stability. Contrast that with the top-down dictatorial approach which comes from the systemd people: you'll use the system the way we tell you to, and no, we don't approve of you doing anything non-standard unless we like it (and good ideas only come from us, so forget it). And if you do change stuff and it breaks, that's 100% your fault since we don't care to consider this. That's the real difference, the attitude and thought behind the design, and how that affects your freedom to use your system as you see fit. And that's one major reason why my servers now run FreeBSD.
sysvinit (or any init) does not need to have a lot of features, so long as you can build more complex features and functionality on top. The very essence of modularity and substitutability. The priority is to be minimal, reliable and bug free. Just look at how many other systems run more advanced stuff on top of sysvinit. It doesn't have to be there in PID1 or provided by the same software package. sysvinit had a very clearly-defined role and within that constrained scope, it provided a working robust solution that worked for multiple decades. The design of sysvinit can be described in a couple of paragraphs of text; you'd need a book to describe systemd, and I doubt even the authors could fully describe it themselves. Overcomplexity and poor design has a cost, and systemd is already an unmaintainable mess.
The very fact that it had a small interface (signals, initctl, inittab) meant that it could very easily be replaced by other systems (and this was done multiple times). The fact that it was easily built upon meant that there were multiple systems built on top of it. It wasn't perfect, and it didn't have every feature everyone wanted. But the point is that it didn't have to while it could be used as a building block by others. systemd is at one extreme (large, complex, tightly-coupled) while s6 is at the other (tiny, simple, loosely-coupled); sysvinit is toward the s6 side of the spectrum; were I writing it from scratch, I'd lean more towards s6 and strip out the more complex bits into separate parts; PID1 doesn't need to deal with inittab for example, nor with runlevels or shutdown.
The core C code of sysvinit was feature-complete, reviewed, debugged and tested years and years ago. Its original design goals were satisfied, and the project is "done". Software does not need continual churn to mark it as "maintained". The same applies to startpar/insserv and other ancillary bits. If you found a bug in sysvinit, I'd review and test it, and push a commit for it. I no longer maintain the Debian packaging, but I still have upstream commit rights should I need them.
Compare this with systemd. It doesn't have the same clearly-defined scope; it's not possible to say when it will be complete as a result. Software can be complete and finished.
When I was a Biology undergraduate in the late '90s I got several haranguing lectures by various researchers about GMOs and how awful it was that people were against them, how safe they were and how they were the experts and knew they were fine. I later checked, and they were funded by Monsanto, Novartis and other big agribusinesses. Being funded to do fundamental research by big companies can introduce bias, and in some cases it's quite unsubtle.
The big problem I have with claiming something is "safe" is that it's often in a very narrowly-defined and short-term scope. In the case of GMOs, that's often limited to "safe for human consumption" ("because we fed it to rodents for a few years with no ill effects" or similar). What about the effects upon people and the environment in the long term (many decades)? Contamination and change to wild populations of the same organism, for example.
The problem I have with it is that it's easy to prove something specific is safe while ignoring the bigger picture. We were assured that glyphosate was safe for bee populations. It had been tested in the lab and we knew its toxicity precisely. But it later turned out that at sublethal doses it screwed up their navigation leaving them unable to make it back to their hives. That hadn't been investigated, and that was an important part of the bigger picture. It wasn't toxic but it was still deadly.
When such important glaring omissions are made, which could potentially destroy our agricultural productivity, leading to starvation and civilisational collapse at the extreme, it also makes you wonder what important but uninvestigated aspects there are in all areas of science. GMOs might be "obviously safe" to the intelligentsia of the present, but who knows if it will be quite so obvious in 30 years time if some fatal flaw is discovered. While it's clearly profitable today, and it might well be safe, it doesn't hurt to have a sensible amount of caution when our entire population is critically dependent upon this stuff for our continued survival.
In all seriousness, while Unicode is intended to be universal, I don't think that bullshit emojis have a place in it. We have markup in addition to characters, not to mention SVG and other formats which can better represent them. They don't have to be in the Unicode standard.
Support bacteria -- it's the only culture some people have!