In both cases, you trust the publisher and in both cases the publisher gets equal access to your machine.
Oh - you mean you're downloading the source code, then audit it, then compile it and only then you run it?
That's super great. That has saved you from the xz backdoor and all other supply chain attacks and will be of great help to you in the future. Let's hope no backdoor ever slips past your code review.
The difference is that the attack vector of the shell script is an easier target.
If someone was to be malicious; they could manipulate the script and inject some sort of payload in disguise. It's an easier vector to damage than say an compiled package. One that's less prone to being detected in that the script could go for days undetected.
With the executable you can compare the checksum and with the whole package compiled it is less prone and more tricky to alter.
Unless that script is under monitoring 24/7, I'm going for binary but they don't support BSD anyway.
It's much, much easier to hide a malicious payload in a binary than an easily auditable shell-script. And it's much easier to make a decision of whether the payload should be enabled or not if you are already running on the local machine.
If you don't trust a publisher, you really can't run anything of theirs. Shell script or, especially, binary.
Even if it's auditable, how many people are actually verifying the shell script before hand?
You've just been given a command to download and execute.
And the potential of having lots of users downloading a shell script has a quicker attack path than users downloading the package. You have custom repos, holding their own distro packages for the software.
[1] Standard “GNU”/linux desktops