Unlikely, for the same reason that he didn't tackle application packaging[0]: because writing a successful init system would necessitate either perfect backwards compatibility with shell scripts (next to impossible unless you're basically just copy-pasting sysvinit) or a massive coordination problem of rewriting the long tail of all the crazy different daemons people run to be compatible with the new system.
Git didn't have this problem because:
0. Version control systems don't have to interact with as many other software packages anyway (editor/shell integration is nice, but you can live without them and just run git directly from the command line);
1. There were compatibility layers that let Git talk to popular VCSes;
2. The fact that you use Git personally does not affect anyone else, obviating the bulk of the need for coordinated upgrades (there were stories, from before GitHub was a thing, of 'guerrilla Git users' in companies that officially used CVS).
These three things ensured that a relatively painless incremental upgrade path existed; in the case of init systems, it will be much harder to establish.
Git didn't have this problem because:
0. Version control systems don't have to interact with as many other software packages anyway (editor/shell integration is nice, but you can live without them and just run git directly from the command line);
1. There were compatibility layers that let Git talk to popular VCSes;
2. The fact that you use Git personally does not affect anyone else, obviating the bulk of the need for coordinated upgrades (there were stories, from before GitHub was a thing, of 'guerrilla Git users' in companies that officially used CVS).
These three things ensured that a relatively painless incremental upgrade path existed; in the case of init systems, it will be much harder to establish.
[0] He talks about it in https://www.youtube.com/watch?v=1Mg5_gxNXTo ; can't find the timestamp right now, but it's in the latter half of the video IIRC.