this bit goes into a little detail about the rationale

The design enforces this idea for a couple reasons

The first is that global hooks cause mass breaking upon improvement. From experience, having a system-managed hook which upgrades without a commit often causes a large percentage of repositories to go from green-to-red. The situation is even worse when that update requires a lock-step upgrade (old hook fails with new-hook's expected output, new-hook fails with old-hook's expected output).
Repeatability. You want to be able to check out any version of your code and have it build in a repeatable fashion. This is especially true for your most basic checks (syntax / lint / etc.). If linters are non-determinstic, you're much more likely to develop fatigue or turn them off.
Cargo cult. Since pre-commit caches based on the rev value, you'll immediately start drifting across all of your machines. From practice, it's not uncommon that a pre-commit cache lives for many months or even years! This causes a whole class of "works on my machine" and "oh yeah that thing sucks just run pre-commit clean" which is both a headache and a huge waste of precious developer time.
It's trivially easy to upgrade. pre-commit autoupdate was purpose built to make it easy to upgrade to the latest version. Coupled with pre-commit run --all-files, an upgrade and reformat is a snap.
Even with many repositories (we manage ~550 and growing with pre-commit at lyft) you can use tools to distribute these updates periodically -- for example all-repos has an autofixer which does this example PR

issue a warning if a mutable ref is used (HEAD / stable / master / etc.) #974

Description