for me the downside is mostly when I am forced as user to everything the 'systemd --user' way. All I have are mpd, dbus, pulseaudio, mako which I can easily run from my sway/config (the script that starts sway or xinitrc whatever) and I do not need systemd and journalctl and all the tooling that I'm then also buying into. This is IMO an annoyance where I think systemd is creeping in too much.

From a developer pov I'm optimistic. systemd seems to be positioning itself as a isolation technology. It gives me a simple and effective way to ship security controls that the user themselves would not be able to do with this granularity (well normally) and it's part of the package / installer (e.g. by default hardened because why bother the user?). And the process for me as dev is really simple too (see below).

It gives me additional options rather than just hope everyone will use firejail and apparmor (even on a debian sid apparmor userspace is too permissive or not properly maintained - firejail is better but rare).

some simple things that can be dumped into a systemd.service file (source https://www.redhat.com/sysadmin/mastering-systemd) to ensure hardening isolation/hardening is always shipped with the package.

  RestrictNamespaces=true
  RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6 AF_NETLINK
  ProtectClock=true
  NoNewPrivileges=true
  DevicePolicy=closed
  PrivateTmp=true
  ProtectControlGroups=true
  ProtectHome=true
  ProtectKernelLogs=true
  ProtectKernelModules=true
  ProtectSystem=strict
  RestrictSUIDSGID=true
  SystemCallArchitectures=native
  SystemCallFilter=sendmsg recvfrom sendto getpid prctl brk socket read stat openat rt_sigaction fstat bind close connect getsockname setpriority capset getpriority lseek mmap mprotect munmap access execve getuid capget arch_prctl gettid
  RestrictRealtime=true
  LockPersonality=true
  MemoryDenyWriteExecute=true

As an elitist user, sure firejail is great - but I would not install firejail on my 72 yro aunt Debian laptop (because many reasons :))