I would say there is a difference between constructive criticism and an "attack" and although the privsec article does bring up valid points* I would still regard it as the latter (despite their claims of objectivity), because they ultimately conclude that its premise is inherently flawed regardless of implementation details. They claim
This article aims to be purely technical. It is not an attack on F-Droid or their mission.
Yet while the authors claim to be "objective and technical" its not hard to notice all the "attacks on F-Droid's mission" in this article, from the reference to F-Droid's "ridiculous inclusion policy" to all the dismissive references to "ideology." The message is clear, that F-Droid's "mission" is Stupid and Ideological and the problems F-Droid aims to solve are not real. Thus, their suggested "alternatives" are just regular app stores that don't enforce any of the guarantees that F-Droid does (namely, that the app corresponds to its source code and does not include proprietary components), because those guarantees aren't worth anything** to the "Objective and Technical" people of privsec - you are Stupid and Ideological if you care about software freedom. In fact, Accrescent even says they allow proprietary software because free software "is not inherently more secure or private" - which is technically true, but very misleading, because free software never has claimed to be "more secure" - it has only ever offered the four freedoms, which as a user I feel entitled to on my own devices, so I only install apps that give me these four freedoms. Far from being "objective and non-ideological" the position of Privsec, Accrescent, and their advocates is that users neither deserve, need, or should want software freedom, as such I would characterize these organizations as hostile to the free software movement even if some of their points are factual.
I will add I am not entirely uncritical of F-Droid either, but my criticisms are more that they aren't strict enough and should be building as much from source as possible instead of relying on prebuilt Maven dependencies as much as they do. I would also say although as a user I think F-Droid's inclusion policy is a good thing and not "ridiculous" I agree it does put some amount of burden on developers who I imagine develop for the Google world first and the FOSS world second. It might be a good idea for F-Droid maintainers to take a more active role in, well, maintaining these apps instead of pushing the extra work onto the developers (this is typical in the GNU/Linux world, in which distro maintainers take up all the work to package upstreams, but F-Droid sometimes tries to cosplay as an "app store" despite it being a fundamentally different model).
* aside from a bizarre claim that F-Droid supporting multiple repositories is a Bad Thing because it interferes with, and I quote, "UserManager which can be used to prevent a user from installing third-party apps" - what does this have to do with privacy? I think this also speaks to a deeper conflict between security people and free software people, that being uncritical worship of "security models" even when they harm the user. Accrescent offers more or less the same justification for why it locks the user into their own store/repository, and I think it is subtly dangerous to suggest this is an "alternative" to F-Droid because it has very different values.
** According to one of the writers of that article,
Any better ideas for it are welcome.
Just allow devs to upload their own build with their own keys like Accrescent. It's not like the whole "audit" system is meaningful anyways.
Of course, characterizing it as an "audit system" is missing the point entirely, but I imagine he knows that. Reducing the four freedoms down to "you can look at the source code and audit it" to then follow it up with "you can't/aren't going to audit every app you download so why bother with FOSS anyway" is a favorite rhetorical tactic.
The thing is, there already is a flow to enable "unknown sources" with the appropriate scare messages. So whatever "advanced flow" they're going to come up with is going to be more involved than that.
My guess would be something similar to the bootloader unlock flow, where it resets the device and sets it to some "unsafe" state similar to a rooted/unlocked device which banking apps etc. can detect and refuse to work with.