Good performance with traditional tracing GC's involves a lot of memory overhead. Golang improves on this quite a bit with its concurrent GC, and maybe Java will achieve similarly in the future with ZGC, but reference counting has very little memory overhead in most cases.
> Reference counting when an object is shared between multiple cores require atomic increments/decrements and that is very expensive
Reference counting with a language like Rust only requires atomic inc/dec when independently "owning" references (i.e. references that can keep the object around and extend its lifecycle) are added or removed, which should be a rare operation. It's not really performing an atomic op on every access.
A tracing GCs can do the job concurrently, without slowing down the actual, work-bearing threads, so throughput will be much better.
> Golang improves on this quite a bit with its concurrent GC
Not sure what does it have to do with memory overhead. Java's GCs are at least generation ahead on every count, Go can just get away with a slower GC due to value types.
On the other hand, systemd replaces Unix (sort of like Hurd, but differently). It grabs system init, logging, authentication, DNS, session management, cron, daemon monitoring, socket activation, running containers, etc. In an ideal Red Hat world, I suppose, a bare-metal box should contain a kernel, systemd, podman, IP tools, and maybe sshd and busybox. This is a very anti-Unix, mainframe-like approach, but for a big consulting firm, like Red Hat / IBM, it is very attractive.
First of all, it wasn't "thrust upon" anyone, it was democratically selected multiple times in a ranked voting setup in case of Debian, and independently by Arch as well. It was simply because maintainers were fed up with the absolutely unmaintainable mess that predated systemd -- it seems random-ass bash scripts are not suitable for such a complex problem as booting up a system, and doing it properly is much better.
Logging sucked great time before, e.g. you didn't even get logs from before the Linux kernel is started - systemd moves it to a single place. And if you are for some reason irritated by binary logging, you can just freely pipe it to text logs.
Authentication is not done by systemd, are you thinking of pam modules? The network service is not systemd, just runs under the same group's name - KDE file browser is also different from their terminal. Also, it's not mandatory to use. Logind is not systemd itself, again. Scheduling services makes absolute sense for systemd's problem domain, so do monitoring and socket activation.
You need some kind of order to build stuff on, the Unix philosophy is more of a feel good convention than a real design guideline (and it doesn't apply in many cases)