Yes, that means that the binding process is done in init -- not the daemons. So, init doesn't need to wait for services to do this on their own. It hands the sockets to the services when they are fully launched. Where SysVinit will only start a service once services it depends on are running (because of sysadmins careful naming of their start-up scripts), systemd moves ahead without concern.
An example is that of syslog and D-Bus (desktop bus -- and interprocess communications mechanism used in the Linux kernel. SysVinit will not launch D-Bus until the syslog service is running. Systemd will create /dev/log and launch both D-Bus and syslog at the same time.
Because systemd both creates and maintains the sockets, it can re-launch services without causing services that were connected to those sockets to lose their connections. Again, what an impressive innovation! Though I understand some credit belongs to Apple due to similar innovations in its launchd.
What this means to Linux admins is that, with systemd, our concerns about slow boots, service dependencies and service failures are going to be dramatically reduced.
I remember back to the days in which the boot process was controlled by two big scripts -- /etc/rc and /etc/rc.local. The System V start-up system that, for me, became a part of my life with SVR4 (the big merger between System V and BSD) was a welcome change and I quickly grasped the steps in the process and tended to my rc scripts. What I'm now seeing in systemd has me saying "Wow!!!!!". No doubt about it, this is the better way to boot!