In my mind, it mostly is about curl|bash not being auditable. On the spectrum of [auditable to not-auditable], curl|bash is as far to the right as possible, with things like distro packages far to the left. Maybe for a specific piece of software that's okay, but I think we would readily agree that it'd be a problem for all components of an OS to use bash|curl.
Bear in mind that, like many bits of security advice, this is highly context-dependent. It may vary based on your risk tolerance, your level of trust in the vendor, how robust other parts of your infrastructure (e.g. threat monitoring tools, network segmentation, etc.) are.
Detect AND change what is sent from the server. So you open the link in a browser and see that the remote shell code is fine, does what you want, then you `curl | bash` it and it sends a completely different program to run.
If you trust where you are curling from, and you trust everyone they trust and that they definitely haven't been hacked, then great! Blindly eval that code! That's what I do :)
The threat model where a malicious server can trick curl|bash but not the alternatives is extremely narrow. Reacting to curl|bash is missing the forest for the single tree.
It is not a security problem if you know what you are doing and trusting the source. As a general way of installing software is is problematic because it is a risk when careless users execute untrusted code from the internet. Using this in cases where it could be seen a safe encourages such unsafe behavior and undermines efforts to train users not to do this. There is also the issue that websites are generally less safe than dedicated infrastructure of distributions. Those also typically ensure some level of quality control and auditing.
If I want to run a software written by someone, going to that someone's site and grabbing the source and/or binary straight from them seems like a pretty straight-forward decision, you don't need some middle man of a "distribution maintainer".
Besides, while I appreciate the efforts of the distro package maintainers, they are overworked and can't really give the amount of care this huge pile of software in the repository needs, not to mention that sometimes their efforts are counterproductive (IIRC Debian used to deliberately break some terminfo(5) records to work around problems in some other packages). And I definitely remember reading an article (though I can't for the love of me to find it) about a Linux distro doing an automated switch from some sort of RPM-like packaging to straight-up using Flatpak, with predictably horrible results of lots and lots of broken software.
