The XZ attack is (seemingly) exclusively targeting openssh.
Considering it's a library that isn't even a direct dependency of ssh and someone was willing to put in over two years of effort, it doesn't seem crazy to start wondering what other (small) projects have been suffering maintainer fatigue or are even just big enough where a "lgtm" response is almost guaranteed by a sane looking PR.
"Smuggle in unexpected code/blobs as test files", "bastardise make scripts to inject your code into the build" and then "have your code preferentially override [decryption] routines" aren't just (as of last week) unexpected, but would also seemingly be usable against any other project out there.
I'd suggest it's more like finding and killing a cockroach in your bathroom. Thinking that the roach problem is now gone for good and was only confined to the one room seems... optimistic at best.
I also think it's fun to wildly speculate on what else could be affected - or to play the game another way, "if I had control over sshd, what else would I want?"
From an outside point of view, I'd quite like web servers. They're often externally accessible when ssh isn't, are doing cert validation/compression/decryption and I'd wager on most boxes, could easily give you an ssl wrapped tunnel to (the vulnerable) sshd running on the servers loopback address without selinux blocking you.
Actually, having written that, has anyone looked at the SSH _client_ process rather than server? Surely it needs to be able to parse certs in the same way as the server does, and getting clients to leak their private keys somewhere seems like it would be extremely useful as well.