I’m actually not sure.
There is one counter argument to it: I often choose the packages I frequently depend on by the author/maintainer, less so by features and API. Do I trust them, do I know they’re experts and not just dumping an experiment on hackage?
There’s maintainers I have personally blacklisted, because I don’t trust them to maintain e.g. secure packages.
When a package takeover happens, it’s often hard for users like me to know and reevaluate whether I want to trust the new maintainers.
I guess that could somehow be assisted with tooling, but often times the maintainer field in cabal files isn’t very reliable. Or I simply have never heard of the new maintainer and their hackage footprint is zero.
As such, fluid maintainership can disrupt the trust relationship between users and package.
I’m not advocating to stop package takeovers, but e.g. hackage namespaces could solve this problem.
Edit: that’s also why I’m quite sceptical of things like Haskell GitHub Trust. Do you want lots of people have commit access to crypto packages?