Is there actual proof that systemd is a botnet?

It's not a botnet, it's just stupidity incarnated.
The closest you can get is the fact that is uses google's own dns even when using a vpn, causing massive fucking dns leaks.
There are other such things, like how you can use a systemd function to delete the root filesystem.
Someone really needs to write down a full list of retarded shit this thing has done.

HOLY SHIT ALL CABLES REALLY ARE BOTNET!

Absence of evidence is not evidence of absence.

its giant funnel that ties components together often for no reason
like Windows 10 has its services tied together somehow, so if you try to get rid of things you dont need, it keeps resurrecting them and starting them up, that didnt happen so aggressively or at all with Win7
something similar is happening with systemd, it ties everything together to take control away from you

The issue is less about systemd being botnet, and more about systemd being hard to audit, forced on users, poorly encapsulated, and developed by untrustworthy individuals.

almost true, if you consider antonymous nation state actor dragnet to be botnet (which yes that is not the real definition).

sytemd's timers are for people that somehow never heard of cronjobs, which contrary to systemd's approach of reinventing the wheel, (badly) actually have sort of a standardized way of how to do them between them and are in some cases even transferable between the different daemons that exist. Personally I use fcron with runit, which also doesn't expect my computer to be running all the time to work properly. You have to be an absolute brainlet to not be able to wrap your mind around crontabs, especially with the sheer amount of documentation that's out there.

The funny thing about systemd is that one of the reasons it was claimed to be written for (quicker startup, as if that even fucking matters in any way) it doesn't really fulfill anymore, there are much simpler init systems that are a lot faster in booting and shutting down. It's literally not better at anything, you just have to learn the ass-backwards way the scripting of systemd works which is knowledge that isn't even transferable onto anything else as it only applies to systemd and also might be outdated and pointless any release as the devs of systemd don't deem it necessary to stay backwards compatible.

On top of that, it has a bunch of shit added to it in some flurry of developer ADHD that plain should not be in an init system. Shit that's interestingly also not easily removable, seemingly on purpose. The last one reeks of politics and Red Hat shenanigans, especially observing how aggressively systemd was marketed (I'm aware it's free but it's so aggressively shilled that it reminds of the strategies of the likes of Microsoft in the 90s) and how aggressively it's incompatible on purpose with stuff or doesn't let other projects use parts of it without pulling the whole blob in. That's where the conspiracy theories come in. I think it's much more mundane than that and Red Hat simply made a push to control the Linux userspace and wants to turn it into an unmanageable mess like Windows is to secure support jobs.

Re: The parallel start and deaemon dependency meme: This interdependency programming in inits so that daemons don't fail when specific conditions are not met is solving the problem from the wrong direction. A well written daemon acts gracefully if the resources it needs are not available (yet) and I am personally not aware of a single one that's so garbage that it doesn't. Even OpenVPN patiently waits and retries until a network connection is available. If you find one, you better should seek an alternative instead of writing a mess of an init system around it, or bug the developers and ask them why their daemon is garbage.

Even most normie and pajeet computer janitors seem to start to realize that systemd is kinda garbage but they have now invested time in it and inertia is big in IT, so I guess we'll be stuck for it for a while, no matter how much more garbage it becomes.

you also have to realize that corporate endeavors like red hat live from reinventing the wheel. If they make a product that just works well and doesn't need maintenance, they're out of a job. That applies to any industry and to capitalism in general.

The optimized startup is to support the whole containerization/microservices fad. In the olden days you basically never reboot your linux box so startup time was irrelevant like you said but since spawning containers on demand became a thing so arose the need for a new init system.

You're looking at this from guy-in-his-basement perspective. In the corporate world you have no control over shit your boss wants running on 100s of machines. So Redhat providing a robust init system that can handle shitty init scripts is actually providing value to customers.

There's a big difference between garbage and solving problems you don't have. It is regrettable that so many community distros did the easy thing (from a packaging/maintainer perspective) and went with systemd instead of something more suitable for home/personal use. They are the ones you should be mad at.

that is not true, but if you are a low level pajeet then probably yes.
problem is that if you have running the same thing on these machines for a decade, then vendor decides to push bullshit from upstream, what can you do?
you wait and see.
the vendor gained trust over the last decade, so you rely on his decision.
and so you wait and see.
you make stats of failures, analysis and decide how much money you've lost by their decision.
then you make educated call.
this could take years.
but once the trust is lost, it's hard to gain it back.
problem then becomes, who could replace vendors such as redhat or veritas.