What's the point of your implementation? systemd is totally modular, you can use just the init system without networkd, timesyncd, resolved, nspawn, whatever else I forgot about.
If you want you can just use systemd as PID1 for service management and enjoy a sane way to define and manage services – and do everything in archaic ways like 20 years ago.
* Choice. If I have a separate implementation, my users do not have to be subject to systemd's choices. And I do not either.
* The same implementation will have the same bugs, so in the same way that redundant software has multiple independent implementations, having an independent implementation will avoid the same bugs. It may have different bugs, sure, but my goal would be to test like SQLite and achieve DO-178C certification. Or as close as I could, anyway.
I'd assume chances of monetizing this are incredibly low. There already is an init system that understands systemd unit files, the name escapes my mind unfortunately. DO-178C might be a selling point literally, but whether there's enough potential customers for ROI is questionable.
Well some distros might force more components upon you but thas hardly systemd's fault. Same if some software decides to make use of another component of systemd - then that's their choice, but also there are alternatives. The only thing that comes to mind right now would be something like GNOME which requires logind, but all other "typical" software only wants systemd-the-init-system if anything. You can run Debian just fine with just systemd as an init system and nothing else.
What about sponsors? Actually, now I have the idea of a platform similar to Kickstarter but for software development, and with just sponsors. It wouldn't work, sure... Except in some cases. Like when things like this happen...
The problem? It's on the backburner because I don't think I could find a business model to make money from it.
I don't think offering support for a price would work, for example.