That was one factor of multiple, and the malicious actor chose to exploit it that way. liblzma is in enough critical stuff that they could have chosen to exploit something different had it not been for that.

You're confused there. The xz backdoor made use of a Debian OpenSSH patch, but it wasn't "caused" by it. Without the patch, the malicious xz maintainer could have written a different backdoor without making use of the OpenSSH patch -- for example, since debian packages are compressed with xz, the backdoor could have modified the sshd binary while unpacking the next OpenSSH security update. That would have been slower (attacker might have needed to wait a long time for a security update), and more discoverable since the modified file would be persisted to disk; but it also wouldn't have caused the performance issues that ended up in the discovery of the backdoor.

this is such a spin! that bug was two years worth of James Bond-level insertions into a situation that "was caused" by systemd ! if you want to get creative in the rewriting of fact

Do you really think there was no other avenue? There are tons and tons of things that link against liblzma, including stuff that commonly gets run as root such as apt, udev, and grub.