I've tried but couldn't find the issue that addresses exactly this problem, so I'm creating a new one. Please let me know if there is, or any misinformation I have.

According to this comment by a GitHub engineer, it seems using GitHub (or any Git-based solution at all) as a package manager's backend causes severe damage to the tool's performance.

I have recently attempted a Haskell "boot camp" at the company I'm working at, and recommended all participants to install Stack. The most frequently raised inquiry/complaint was that it took ages to install. Some people reported "70 minutes and still not complete." It's 2016, and I think we can agree that if a programming language's tooling takes more than an hour to download and install, something's certainly wrong. As @snoyberg pointed out, the time it takes to actually use it is important, so we should consider this not a performance trouble but a blocker for anyone who ever attempts to enter Haskell.

Although less dramatic, the problem with a Git-based backend is not limited to the initial installation, but pervasive in the whole tooling. For example, suppose I'd like to choose the latest nightly as the project's resolver. A shell script like

sed -i 's/^resolver: .*/resolver: '$(curl -s https://www.stackage.org/snapshots | grep -o -m 1 "nightly-[0-9]\+-[0-9]\+-[0-9]\+")'/' stack.yaml

takes less than 1.5 seconds to run because the heaviest task here is to download one HTML file. On the other hand, Stack's built-in command for the same task, stack --resolver nightly solver --update-config, may take more than 10 seconds because it has to git-fetch a repository that contains more than ten thousand commits regarding more than nine thousand files, which is generally expensive according to the aforementioned comment.

One solution I can think of is to make the Stack command line tool switch to using an independent server (e.g. the Stackage website) as backend and avoid GitHub. If Git or GitHub is necessary for versioning or something, that's fine; we can still rely on it, just make it cached or mirrored somewhere so the command line tool won't directly depend on them.