F-Droid is in fact what an app store concerned about user safety looks like. Nobody gets hoodwinked into installing apps that track them or sell their data or otherwise abuse them on F-Droid.
F-Droid is so irrelevant that it doesn't even begin being targeted by supply chain and scam attacks. Being obscure always help with this, but pretending that it's the same threat model is absolutely false.
The XZ utils backdoor made it into Debian repositories undetected, although it was caught before it was in a stable version.
Debian repositories are quite secure, but also pretty limited in scope and extremely slow to update. In practice, basically everyone (I'm sure there are a few counterexamples) using a Linux distro uses it as a base and runs extra software from less tightly controlled sources: Docker hub, PyPI, npm, crates, Flathub etc. It's far easier for attackers to target those, but their openness also means there's a lot of useful stuff there that's not in Debian.
Holding up Debian as a model for security is one step up from the old joke about securing your computer by turning it off and unplugging it. It's true, but it's not really interesting.
XZ attack is an extremely rare event coming likely from a state actor, which actually proves that GNU/Linux is a very important target. It was also caught not least thanks to the open nature of the repository. Also, AFAIK it wasn't even a change in the repo itself.
In short, using FLOSS is the way to ensure security. Whenever you touch proprietary staff, be careful and use compartmentalization.
That article's premise is that the Android security model is something that I want. It really isn't.
The F-Droid model of having multiple repositories in one app is absolutely perfect because it gives me control (rather than the operating system) over what repositories I decide to add. There is no scenario in which I wish Android to question me on whether I want to install an app from a particular F-Droid repository.
Can you describe the threat model / specific attack under which... any of the supposed flaws on that page matter? (Most of the particular section you've linked appears to be about extra defenses that could be added, but which are unlikely to make a difference in the face of Android's TOFU signature verification on installed APKs.)
The section you linked in particular is a load of editorialized bullshit IMO. As far as I can tell the only legitimate complaint is that there is (or was?) some sort of issue with the signing methodology for both APKs and repository metadata. Specifically they were apparently very slow to replace deprecated methods that had known issues. However it's worth noting that they appear to have been following what were at one point standard practices.
The certificate pinning nonsense is particularly egregious. APT famously doesn't need TLS unless you're concerned about confidentiality. It's the same for any package manager that securely signs everything, and if there's ever a signing vulnerability then relying on TLS certainly might save you but seems extremely risky. On top of that the Android TOFU model means none of this matters in the slightest for already installed apps which is expected to be the case the vast majority of the time.
As far as I'm concerned F-Droid is the best currently available option. That said of course there are places it could improve.
