This is what I prefer as well. Let me use my OS's package manager for managing my packages.

That would still be the case if the packages weren't 1-3 years out of date.

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).

3) Install from source

4) Install via language-specific package manager

5) Install via curl | sh :)

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.