Because it's a security tool so trusting a binary upfront defeats the purpose. With source you at least have the option to inspect what it really does.
Certain tools are more likely to be used by people working in spaces where they should/must be less trusting.
If there was a tool (there is) to scan my platform deployment against some NCSC/NSA guidance for platform security, and I wanted to use it, I'm likely operating in a space that should consider being cautious about running random tools I find on the internet.
This is argumentum ad absurdum - there is a reason why trusting your kernel and compiler is a reasonable compromise, even though there might be security issues in them, but random pieces of software downloaded from the Internet is not.
Wait ... you download random compilers from the internet? Or are you asserting equivalence between getting go from Google or Xcode from Apple and an random home brew install?
also if you're not trying to improve the security of your product by running random binaries from the internet. I'm concerned at the inability to separate the concepts of "what it does" and "what it says it does".
The idea that whether or not it needs scrutiny is impacted by your goals with the software is... creative
Uh? OP just released a docker image and wants to release a homebrew thingy. Even assuming that was you say is somehow sensible, it's not the reason, no. You're just grasping at straws.
The docker image is nothing more than “FROM scratch” and then copying in the statically linked binary. If there are 0 other dependencies, I think it would be equally easy to distribute the binary through GitHub releases. There is no need for brew.
If people want to run it isolated, the docker image is of course still a nice to have and docker hub is a convenient distribution mechanism. At the same time, an equivalent image can equally easily be created by the consumer.
Personally, due to trust, I would anyway still build it from source and run in a container, to be on the safe side.