I'm not going to go into the curl|sh debate, but there is actually something wrong about what you described. Trusting the server doesn't apply to Github at all.
Github is technically like a bazaar or mall. It's wrong to assume that if you trust a store on the bazaar you then trust ALL stores on the bazaar. You personally may, but then I strongly question your sense of security. Sure, you trust that Github doesn't add malicious stuff when cloning, but each repo on Github is kinda it's own "server" to fit into your analogy.
The link being used in the curl-to-bash example from the original discussion is a direct link to content in the repo itself — so if you trust that repo server for its content, it doesn't matter whether you curl-to-bash or not. If that Github server is malicious you're in trouble.
FWIW though, if Github servers have a vuln that allows attackers to modify repo content being served on a per-request basis, it's pretty likely that many repos (or even all repos) would be vulnerable, not just one. From a security standpoint I'd consider Github repo servers to be a tier of servers that you do or don't trust; saying that you trust one "server" within the tier but don't trust another doesn't make a lot of sense, especially since you don't actually know the topology behind their DNS and the "servers" are virtualized, colocated, and parts of them are ephemeral. What exactly are you trusting? Other than "I sent a request to Github and it gave me a response" there's not much you can say for certain — the request could've been routed to any number of repo servers, that may be hosting dozens of other repos on them as well. The server that responds today is likely a different virtualized server than the one that responds tomorrow, just attached to the same filesystem. But even if that weren't true, curl-to-bash in this example seems ultimately fine for most people.
If I were doing devops work that required Kubescape for an org, I would definitely package it into a deb (or whatever package format the org used internally) and install it that way rather than curl-to-bash. But that's not because of security gains from a deb vs a script, that's because I'd want to lock it to a stable version rather than always installing latest, and I wouldn't want to tie availability of Kubescape to Github repo servers being up (they do go down sometimes). But for getting started playing around with it, curl-to-bash is low friction, can easily support multiple OSes as compared to debs, and seems generally fine as it is used here.
Github is technically like a bazaar or mall. It's wrong to assume that if you trust a store on the bazaar you then trust ALL stores on the bazaar. You personally may, but then I strongly question your sense of security. Sure, you trust that Github doesn't add malicious stuff when cloning, but each repo on Github is kinda it's own "server" to fit into your analogy.