The problem is more that the Arch value proposition kinda presupposes the sort of user that's going to "feel superior" about having it installed[0]. It leads to people that have no business installing Arch Linux (as it doesn't match their usecase) installing Arch Linux because it makes them feel cool.
I don't have a good answer for this, besides making it more apparent what people should expect from having Arch installed. My recommendation usually goes something like this:
* Do you want to have the latest version of all software, regardless of the question if it's well-tested beforehand?
* Do you want to have all software distributed in an as-close-to-upstream approach as possible? Be aware that "upstream" configuration can sometimes significantly differ from defaults most people expect. (Sometimes there's reasons for this, sometimes upstream are a bunch of obstinate jerks.)
* Are you comfortable with a terminal?
* Are you comfortable with needing to suddenly learn how to troubleshoot a broken system after a routine update?
Only if the answer to all of those is "yes", then Arch is suitable for you.
And finally, more specific to servers, where the answer should be "no" if you want to use arch:
* Do you have the expectation to never have to touch the OS after it's been configured correctly besides routine maintenance (ie. installing security updates) and maybe a big update twice a year?
I used to use Arch, before realizing that my system was gradually morphing into a bespoke mess that didn't really serve my needs and that while doing something very specific was possible, I also had to configure a bunch of mundane stuff you aren't normally required to think about - there's never a "just install, activate and adjust as needed" with Arch. All I actually wanted was a distro with more recent software than "3 years old" (Debian/Ubuntu's sluggish package inclusion is not really useful for desktops).
So I looked around and realized Fedora worked better for me: professional, clean, recent software (every 9 months updates, feature freezes are smart enough to account for ie. New Python releases) and not prone to sudden surprises.
[0]: https://wiki.archlinux.org/title/Arch_Linux is a good example of it.
Sorta like 'car guys' who recommend some old thing you can wrench on.
Arch still hits the sweet spot for me -- unobtrusive, close to upstream, and well-documented enough to keep full control over your own system. Both for the times when you want to go with the most default path and for the cases when you want to deviate and go play in the weeds.
Now, someone could argue that the Spotify app isn't important, but there's a reason it has 268 votes. A better solution would be having packages like spotify in their own repo, and a separate, you-better-verify repo for the rest.
[1] https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=spoti...
> Now, someone could argue that the Spotify app isn't important, but there's a reason it has 268 votes. A better solution would be having packages like spotify in their own repo, and a separate, you-better-verify repo for the rest.
I mean yeah, but everything is trade off of volunteer + user attention. There is no trusted user™ who uses spotify, so it's not in official packages. So you as user need to maintain it yourself or rely on AUR and verify.