I think a micro-kernel architecture would be better in many ways, security being just one of them. With GCC, it couldn't really be separated into logically distinct modules any more than it already is. All of the constituent parts essentially use the full functionality of the base compiler part, so there is little to be gained separating them. It's not as if the C compiler from GCC, could for instance, be written in such a way that it doesn't depend on GCC. GLibc is a large implementation, but the library itself doesn't necessarily need to be large. There are some very small libcs out there.
On the whole, I do not like monolithic software projects, but I can accept that they are necessary or beneficial in some cases. Systemd is simply a much bigger target than these other things because it is an especially bad example. It has many components which are only tentatively connected. It is also more fixable. Alternate init systems are used much more widely than something like Hurd to replace Linux. The laptop I'm typing this from runs GuixSD which ships without Systemd and I can hardly notice the difference. I doubt a different kernel architecture would provide such a seamless experience.
Given how common LZMA as a compression algorithm is, are you certain that your init system of choice doesn’t use it in any way? It’s a very common algorithm in network protocols, it’s a direct dependency of libxml, … - and if any part of your init system uses LZMA, then it just happens not to be affected because the attacker chose to target one specific system.
The attacker had essentially full control over a very fundamental library in the Linux ecosystem. They could have leveraged that in a hundred ways.
The attacker chose to target a very specific component of a very specific system. It was their choice, not some sort of technical requirement that made it impossible to use a different attack vector. Just as they chose not to target other Linux distributions that use systemd.
You’re essentially saying “I was safe because the attacker chose to ignore me.” That worked well this time, but it’s a pretty dangerous stance.
When a hacker chooses to attack something, that isn't random. They had to look at a lot of different pieces of software, and decide which would be the best to attack. The choice in this case was Systemd. In other words, if you are looking to do malicious things, Systemd is helpful.
Now I want you to imagine that every piece of software has a score, which tells you how useful it is to hackers. Systemd has a high score, and hence it was chosen for this attack. Your argument is that: there are other pieces of software with a high score so it's fine for Systemd to also have one, since without it there would be other things to attack. My argument is that we should reduce the amount of software that has a high score. Do you think my reasoning or your reasoning will lead to a more secure ecosystem?
On the whole, I do not like monolithic software projects, but I can accept that they are necessary or beneficial in some cases. Systemd is simply a much bigger target than these other things because it is an especially bad example. It has many components which are only tentatively connected. It is also more fixable. Alternate init systems are used much more widely than something like Hurd to replace Linux. The laptop I'm typing this from runs GuixSD which ships without Systemd and I can hardly notice the difference. I doubt a different kernel architecture would provide such a seamless experience.