Yes that's a great point. I wish distros would force all mirrors to be TLS. Security should be the default. If users want to use a fast insecure mirror, they can enable that option at their discretion.
In this case they're related because of supply chain attacks. If an attacker learns that you're using a small obscure package, they might be able to hack the developer's machine and insert a backdoor or bugdoor.
I suspect you could extend that line of logic to always combine privacy and security. Which, granted is not exactly wrong, but that's just security through obscurity and you really shouldn't rely on it.
(Of course, if it's free then you should strongly consider taking the obscurity, and privacy is a compelling argument all on its own. I just think blurring the line here is iffy.)
I'd argue that privacy and security are unavoidably related. Is keeping your password secret about privacy, security, or "security through obscurity"? Depends which term you want to use :-)
IMO the concept of "security by obscurity" is overused. Ultimately what matters is the cost for an attacker. If you're trying to design a secure system, your system will be stronger if you put it out there for people to criticize instead of keeping the details secret. This argument doesn't really apply to encrypting the packages you use. Security solely through obscurity isn't ideal, but what really matters is the cost/benefit ratio. It's way easier to encrypt your package downloads than it is to read all the source code changes on every package update. (Does anyone even do that?)
I'd even argue that security is a general concept, and for communication, includes the concepts of confidentiality (privacy), authenticity, and integrity.
