[xylophile]

> Why is ordering startup important?

This is pretty fundamental stuff. You can't run a program if the disk that it's sitting on hasn't been made accessible yet. You can't start a network service that listens on a certain IP address if that IP address hasn't been configured yet, or if the destination for service logs isn't ready, or if our service needs to talk to some other service like a database which isn't running yet. Etc etc. Booting up a modern system to a graphical environment requires hundreds of things to happen in the right order.

As for everything else, the project announcement blog post from 2010 does a pretty great job summing up the shortcomings of doing "the simplest possible thing": https://0pointer.de/blog/projects/systemd.html . You can certainly still do things that way if you want, but most people value the benefits gained from a more intricate approach.

[rendaw]

Ah, thanks for the link! So it has an interesting point, which is socket/device activation. And services that aren't started immediately could also have dependencies you don't want to start immediately.

I can see that being important for a desktop, where you're plugging/unplugging stuff and want startup to be fast.

> You can certainly still do things that way if you want

I think you're putting words in my mouth.

[xylophile]

Sorry, I didn't mean you specifically. I meant, if someone values simplicity above all else, they can choose an init that matches those values (like the one you described). Your approach is perfectly valid given that set of values.

Debian and other distros asked their userbase which values to prioritize, and the users chose what systemd provides. Hope that helps explain "why does systemd exist / why have most distros chosen it?"