These days, my reaction to hearing about new systemd features is usually somewhere between indifference and irritation (I'm going to avoid giving examples, for various reasons). The new IP access lists feature is a rare exception; as a sysadmin, I'm actually reasonably enthused about it. What makes systemd's version of IP access restrictions special and interesting is that they can be be imposed per service, not just globally (and socket units having different IP access restrictions than the service implementing them adds extra possibilities).

As a sysadmin, I not infrequently deal with services that either use random ports by default (such as many NFS related programs) or which have an irritating habit of opening up 'control' ports that provide extra access to themselves (looking at what processes are listening on what ports on a typical modern machine can be eye-opening and alarming, especially since many programs don't document their port usage). Dealing with this with general iptables rules is generally too much work to be worth it, even when things don't go wrong; you have to chase down programs, try to configure some of them to use specific ports, hope that the other ports you're blocking are fixed and aren't going to change, and so on.

Because systemd can do these IP access controls on a per service basis, it promises a way out from all of this hassle. With per-service IP access controls, I can easily configure my NFS services so that regardless of what ports they decide to wander off and use, they're only going to be accessible to our NFS clients (or servers, for client machines). Other services can be locked down so that even if they go wild and decide to open up random control ports, nothing is going to happen because no one can talk to them. And the ability to set separate IP access controls on .socket units and .service units opens up the possibility of doing something close to per-port access control for specific services. CUPS already uses socket activation on our Ubuntu 16.04 machines, so we could configure the IPP port to be generally accessible but then lock down the CUPS .service and daemon so we don't have to worry that someday it will sprout an accessible control port somewhere.

(There are also uses for denying outbound traffic to some or many destinations but only for some services. This is much harder to do with iptables, and sometimes not possible at all.)