I think Guix has like 1/3 the total number of packages available, probably less. This may not be a huge deal— when I started using NixOS, Nixpkgs was much smaller than it is now, too, but it still felt worth it for me. As another user pointed out, packaging in Nix and Guix is pretty easy for anything that doesn't have a bespoke or ill-behaved (requiring network access, trying to write to the directories of other packages, etc.) build system. But it can make a big difference for usability if packaging work is cumbersome for you, or something very large or complex that you want is missing. (I think KDE is still missing, for example.)
Nix flakes are kind of a lot of things: a version pinning system, the switch to pure evaluation mode by default (which impacts caching in a good way but makes configuration slightly more annoying), a distribution mechanism for code written in Nixlang, and a collection of Nixlang schemas which enable a richer command line experience (that, e.g., power the new `nix run` command). It's not clear how many of those functions Nix flakes will retain in its final form.
There's no singular feature that attempts all that in Guix as far as I know, and I don't know the general technical story for evaluation caching with Guix. But Guix does have an integrated, first-party form of package pinning. Where Nix flakes replaces the old 'channel' system, Guix has a richer notion of channels which support pinning in normal Guix expressions.
(In Nix, channels are an output that have a certain structure and get managed in a certain way via fhe nix-channel command to manage them— they're like another type of Nix profile. In Guix, channels are defined by the user directly in Scheme code, just like the rest of their configuratiom, which is more similar to how Nix flake inputs are defined than to Nix channels.)
I've never used Guix channels in anger, so I can't tell you how nice that notion of version pinning is to use.