It basically is. libsystemd links to liblzma for other features not related to notifications.
(The protocol is that systemd passes the path to a unix socket in the `NOTIFY_SOCKET` env variable, and the daemon writes "READY=1" into it.)
It doesn't matter that libsystemd links to liblzma for other reasons. It's still in the address space of any daemon that is using libsystemd for the notification protocol.
For Slurm, I looked at what a PITA pulling libsystemd into our autoconf tooling would be, stumbled on the Golang implementation, and realized it's trivial to implement directly.
There is AF_UNIX support, but only for streams and not datagrams: https://bugs.openjdk.org/browse/JDK-8297837
What an odd decision. I suppose that you could execute systemd-notify but that's a solution that I would not like.
Unless that feature also has some weird limitation, you could probably use that to call the socket API in libc.
What I did was to use JNA to call sd_notify() in libsystemd.so.0 (when that library exists), which works but obviously does not avoid using libsystemd. I suppose I could have done all the socket calls into glibc by hand, but doing that single call into libsystemd directly was simpler (and it can be expected to exist whenever systemd is being used).
Which is pretty emblematic of systemd's primary architectural fault!
If that split had never happened, then liblzma wouldn't have ended up being linked into sshd...