There's a few points to make here, actually, based on discussion of the article in the weeks before it hit HN:

Two major and immediate reasons why the pulling is slow are clear and fixable:

1. Guix will try to substitute from unreachable caches for a LONG time before giving up, and Guix infrastructure is less developed than Nix. When I kept experimenting after this post I set up https://mirror.yandex.ru/mirrors/guix/ eventually which fixes the substitute problems for me (Guix mirror on bigcorp infra).

2. Guix by default pulls its channel from GNU Savannah which, for some reason, is incredibly slow in serving git. The project moved over to Codeberg, and setting the URL to there significantly speeds up pulling.

In NixOS, channels (esp. the unstable ones) advance when CI finishes building a certain subset of packages successfully (this is what https://status.nixos.org/ shows). CI populates the binary cache, so this means that a channel HEAD always has a large number of packages available in the cache. Guix has no such guarantees, so updating to any latest commit might even yield one where you end up rebuilding all of its Scheme from scratch or whatever. Picking a commit that's a few days old helps with this.

I eventually switched to a laptop with a "normal" Intel CPU, and pulling did not magically turn fast. In fact, some of the slowest stages (there's one where it says "Computing Guix derivation") don't seem to exercise the CPU much at all. I haven't spent time looking at why (yet).

Guix System does a lot more per-user stuff than NixOS by default, which means that you'll likely end up pulling multiple times.

Pulling remains a much slower operation than Nix evaluation in any case.

There's a few ways to make this all more palatable (e.g. the `guix time-machine -C $channels` setup), but those might be for a follow-up post in the future.