Correct. Docker containers typically only contain one process, and that process runs as PID 1. If you need an init system, tini is very popular, and is now built in to docker itself[1]. Systemd is way heavy and overkill inside docker.
They don't always have one process though. And this is actually a significant good case for OpenRC, as it is far more lightweight than systemd. I haven't used tini.
Primarily, you would run an init system in a docker container in order to correctly proxy signals to the one process in question, which would otherwise run as PID 1 - for example, sending SIGTERM to docker run running a PID 1 with no registered handler will result in nothing, because Linux won't use the default handler (killing it).
Secondarily, if you want to be neat and save some pids and kernel memory, you need an init system to wait(3) on orphaned zombie processes.
These are the only two use cases AFAIK, which a small init system such as tini satisfies, without the complexity and size of systemd.
That doesn't answer the question: what does systemd provide which isn't needed?
I have multiple network devices. I want some to be controlled by processes running in a container; effectively I want some processes to run under a user account but still provide root (root-like?) access to the specified network device(s). I want to be able to give a specific (containerized) user full control over one or more specific network devices. My (naive?) understanding is that the init daemon takes care of bringing the network online and then subsequent management of it. For systemd, that would be Network Manager? Or do I misunderstand?
[1] https://github.com/krallin/tini