That’s not a good argument. Most of these additional languages are used for separate things, like build scripts and stuff. They don’t affect actual kernel code which is C and assembler language.

It is hard when you mix them in one codebase and need bindings and wrappers for interoperability. This always introduces additional work and maintenance burden. It’s always a tradeoff and for most projects not worth the effort. Tech corporations that do this regularly have dedicated teams to deal with boilerplate bullshit and tooling issues, so that regular devs can just code with minimal friction. Rust-in-Linux community decided to take it upon themselves, but I’m not sure if they can keep it up for years and decades in the future.

Though gradually getting of C is still a good idea. Millions of lines of C code is a nightmare codebase.

Some differences I see: Shepherd does some firewall management with ports, and I don’t see the services it depends on.

That looks like it sets up sshd to start when someone connect to its port, not on boot. You can do the same with systemd, but you need additional .socket unit that will configure how .service unit is activated.

Why this kind of files should be written in a programming language at all? I guess it’s a remnant from the old times, but I like when tools abstract away the programming parts, and users shouldn’t have to deal with that

Systemd invents its own configuration language (it looks like ini but there no standard for that and systemd’s flavor is its own) so you still need to learn it.