A server with ssh generally implies there is a shell, and cli tools, and an administration model that involves humans connecting to servers to manually update them in place like pets.
Having a full workstation-optimized distro like ubuntu or debian with hundreds of packages constantly shifting and updating as a critical production server is wildly high risk in terms of both reliability and security.
I understand this is how most sysadmins were taught but it is a 70s unix mainframe mindset from a time before security was a thing and everyone on the internet was a good actor.
Only a workstation or dev server should have tools for humans like ssh installed.
Production servers should be hardened immutable appliance kernels with read only root filesystems that verify and run signed containers, or run a tiny shim init system in a couple hundred lines that spawns a single application specific binary you trust.
No production systems I launch today even have xz installed, or a package manager, or a shell.
And then you need to debug something. What do?
You could also in some cases have a debug container you pull in on demand, say if the host OS is an appliance-style k8s runtime like TalosOS.
E.g. if you are running an immutable k8s runtime distro like TalosOS or Metropolis, you can choose to pull and mount a debug container with strace and gdb into the same process namespace of a problem pod, and when you are done all those debugging tools evaporate.
System mutability is why most bugs happen in the first place.
There should be no tools or services in prod except those required to run or monitor prod at runtime.
Systemd itself doesn’t even use lzma/xz… libsystemd does, and that’s a library meant to help other software integrate with systemd. It’s not really the same thing.