As indicated by Terdon, this question would need significant refactoring and rethinking to be acceptable on stack exchange.
Interesting questions don't always make good questions.
Your question might be interesting to discuss, however stack exchange largely tries to avoid discussion and especially avoid back-and-forth debate.
What makes a good question?
Either: An Interesting problem described well
As presented here on meta, question describes one problem: "help, I'm inexperienced and don't know which direction next". That's not generally considered an interesting problem. It has one simple and brutal answer: "pick any direction then try it and see; there's no shortcuts to experience".
So you might want to rethink what you are asking and try to pick a solvable problem that others may have faced or, even better, others might be interested in solving for you.
Example:
Is there a way to determine the relative popularity of tools such as runit, openrc, s6, and dinit?
I'd like to chose between these and would like to base part of my decision on popularity, if this information is available. Is there a simple way to determine how popular particular packages are?
Whether or not you regard this as a great question, a good answer to this would put you much further forward. At the same time it is presents a problem which can be investigated. It's not really a discussion topic and does not invite opinion based answers.
Or: Point to a specific piece of missing knowledge
Sometimes you can even ask a question without a problem, but just searching for information. This type of question is tricky because it does need to be specific. It's rarely easy to specify what you don't know.
But there are times where you can. For example by pointing to something exhibiting behaviour you don't understand.
In the question you give us no clue on what it is you don't know. We are willing to assume you have done some reading on those tools prior to asking... its generally expected.
If you can describe some things you've read and explain where "the missing link" should go, then maybe we can help fill in that missing link
Give your requirements
Stephen Kitt pointed out that you hid some of your driving requirements:
Currently, I find myself migrating my computers from archlinux to artix (a fork of archlinux but without systemd) for various reasons.
It's unclear from this phrasing if getting rid of systemd is your intention for making the switch, or just a side effect.
If getting rid of systemd was actually your intent then you might be able to factor an acceptable question over on Software Recommendations.
You really need to be able to express what YOU want from a systemd replacement though. Asking others why they want it will most likely not go well.
Ask about just one tool
Please don't split your one question into 4, one for each tool, that won't help.
Whatever your question is, you should bear in mind that many engineers have a sort of tool box of knowledge. When an engineer discovers a tool that does what they need, they learn how to use it. Now that have that tool they don't have much need for others so they don't bother learning others unless some new need arises.
So if you ask an engineer why they use one tool over another, the honest answer is often "because I've learned that one, not the other".
Questions that ask for side by side comparisons of common tools almost universally fail. They require those answering to have good working knowledge of overlapping tools and usually end up with nothing but people talking about their favourite tool.
In other words side comparison questions very commonly degrade into religious like opinion. They rarely result in pragmatic comparison.
