Again, Cockpit does not explicitly deal with systemd.
Cockpit deals with dbus, and systemd is conveniently available there (hostnamectl, etc). storaged, networkmanager, and other functionality is not dependent on systemd, so it's really just the system journal, changing the hostname, and checking service status which would fail without systemd.
Docker is not required at all either, though it's an option.
That is directly contradicted by Cockpit's own doco, which explicitly states that Cockpit uses the systemd APIs and that "use of alternate system APIs are not currently implemented".
It should of course be obvious that Cockpit does explicitly deal with systemd. Desktop Bus is a transport layer, and the important thing about it is what DBus servers are on the other side of the broker are being talked to. In the case of Cockpit they are things like systemd's own idiosyncratic API for process #1 ...
Yes, cockpit uses hostnamed and timedated. Plus journalctl, which I noted. I'm perfectly aware of how dbus works, and if you think that hostnamed or timedated have 'idiosyncractic' APIs, I'd challenge you to look at the API for glib.
But it uses these because they are readily available over dbus. Not because cockpit has a hard dependency on systemd.
While that functionality wouldn't work, it would be really trivial to write your own using cockpit.spawn() to call `date`... or `hostname ...` instead of hostnamed or timedated. The truth is that hostnamed and timedated are simply better than the CLI tools.
However, I'm sure the Cockpit team would welcome a patch.
More to the point, there is absolutely nothing in Cockpit which is explicitly using systemd APIs outside of dbus, and this would not be hard to work around.
It would be a 20 line patch to break the systemd "dependency" on hostnamed. This is not a project intrinsically linked to systemd.
Even your hardwired "example" of journalctl is literally calling a process, which could just as easily be "cat /var/log/messages". It's 'hardwired' because systemd is the standard these days, whether you like it or not. However, extending the promise to simply do that if journalctl fails is trivial.
Maybe your idea of 'hard' dependencies and mine are very different. To me, a 'dependency' on, say, Python, means that there are Python calls all over the place which a reliance on specific semantics. That means that stubbing it out for Ruby or Lua or whatever would be hard. It is not "we wrote our application with this in mind, but we could patch it into stubbable modules in 3 minutes".
I think you just proved my original point[1]: As shipped, Cockpit will not function as intended on any OS that doesn't use systemd. If it requires patching and legwork the maintainers have not and do not yet plan to implement, it's up to the server maintainer to shoehorn it into their system. That would probably be more work than it's worth just to try out something that may still end up broken with each future update.
Again, no hate for systemd here, I was just pointing out what I had read in the documentation and making it known. FYI my laptop runs Elementary OS which fully depends on systemd and I have no issues with that situation, nor do I "hate" it. If I did I would run a different OS on it. systemd is part of Linux for the majority of distros, it's likely here to stay, and these days it's stable enough for daily use.
Cockpit deals with dbus, and systemd is conveniently available there (hostnamectl, etc). storaged, networkmanager, and other functionality is not dependent on systemd, so it's really just the system journal, changing the hostname, and checking service status which would fail without systemd.
Docker is not required at all either, though it's an option.