You're not making a very good point here. A lot of packages have a transitive dependency on liblzma - for example everything that depends on libxml since that depends on liblzma https://packages.debian.org/sid/libxml2. LZMA is a pretty widely used compression algorithm, I'm absolutely certain there's other juicy targets that depend on liblzma.
The reason why "only" sshd on debian/ubuntu was affected is that the attacker chose to tailor their exploit to those systems. Systemd was the vehicle, debian patching opensshd was what made this specific incarnation of the attack possible, but essentially, both trusted a widely used library.
> A lot of packages have a transitive dependency on liblzma - for example everything that depends on libxml since that depends on liblzma https://packages.debian.org/sid/libxml2.
Sure. But security-critical software like SSH would certainly think twice before bringing in such a huge and complex dependency as an XML parser.
> I'm absolutely certain there's other juicy targets that depend on liblzma.
You could probably make a system package manager (which has obvious reasons to depend on a compression algorithm) do something nefarious. But that would be a more complex chain of exploitation with more chance for things to go wrong. Most security teams put more attention on security-critical parts like SSH, and I think most people would agree they're right to do so.
The reason why "only" sshd on debian/ubuntu was affected is that the attacker chose to tailor their exploit to those systems. Systemd was the vehicle, debian patching opensshd was what made this specific incarnation of the attack possible, but essentially, both trusted a widely used library.