The Yarn developers explain the rationale for this in the Installation docs, in the section called “About global installs”:
Using a single package manager across your system has always been a problem. To be stable, installs need to be run with the same package manager version across environments, otherwise there’s a risk we introduce accidental breaking changes between versions – after all, that’s why the concept of lockfile was introduced in the first place! And with Yarn being in a sense your very first project dependency, it should make sense to “lock it” as well.
Once Yarn is tracked and “locked” as a per-project dependency, it ends up getting committed to Git if you follow Yarn 2’s zero-install strategy, the rationale for which is explained here.
I’m a newcomer to Yarn, but I spent years working devops, helping developers figure out why their code would sometimes build correctly on half of the team’s laptops but not on the other half, or would suddenly start failing to build in CI while continuing to work elsewhere. Trying to keep the version of npm consistent across every computer and codebase in the company was essentially impossible, given that Node is constantly being upgraded, but locking each project to its own specific version of Yarn — which, by being committed to Git, is guaranteed to be available in every checkout of that project — solves this problem.