So the author doesn't care about memory usage or throughput, except for a few "soft realtime" sections? Why would either Rust or Go be better for this task than something like Java or Python?
Java is not really a great choice because you need a JVM for the task at hand. Python is not a good choice because of concurrency constructs, and it's clear that the goal of this was to self-contain the whole thing and not have fringe packages in a semi-direct port from C to a different language. For a raw systems daemon that needs to run on mostly everything being coupled to only one runtime is a huge boon for portability.
That disqualifies Go even more so. You could easily embed a competent JVM in the space a typical Go binary requires to embed all its libraries (the "docker" binary I'm looking at is 13 MB). Go's "Hello, world" is well over a megabyte.
The critical feature here is that the resulting Go binary is whole and complete and tightly coupled to the system at hand, which fits more the output from Rust or C. Inherently Java software is dependent on two runtimes, the JVM and the core libraries the JVM is compiled against. Space isn't the most critical concern here, it is portability and bringing a JVM everywhere is really painful and really a project well outside the goals of the software described. If a JVM was going to be considered a solution this project would have to package the JVM and the daemon which would be silly.
