Its bad both ways. The advantage to python/ruby for example is you can simply pip/gem install, or update. With a binary, you have to download, move, and change permissions every update. For experienced linux users, the binary is fine, but for newer users, its much more "friction"
That is true. But there are ways around that. Including documentation on how to build it locally is pretty standard. And hosting prebuilt binaries with package installation for targeted platforms is also pretty common as well.
With interpreted languages with language-specific package managers, you have to:
1) Install the language
1a) Possibly have to install a language version manager (rbenv, pyenv, etc)
2) Install the language's package manager
3) Install the CLI utility via the language's package manager
Here's the order I think CLI maintainers should strive to making their utilities available:
1) Install via OS package manager
2) Install via prebuilt release with OS-specific package, from hosting site (GitHub, etc).
The problem is, its much easier to support one language package manager, then it is to support 10 different OS package managers, not to mention, some, like debian, are near impossible to push things too.
