I use Guix Home on my laptop (on top of Asahi Fedora Remix) and started trying to use Guix System on my server a while ago. Here’s some points I have:

• The declarative configuration system is fucking awesome and makes Debian feel like the stone age. It does have a high learning curve though but it is definitely worth it.
• When deciding between Nix vs Guix, I ended up settling on Guix because Nix seemed more focused on marketing and cutting corners to make a working product faster and Guix seemed more like a community project with better ideological goals behind it. However, I have hardly used Nix so take this with a grain of salt. Also, Nix has a lot more packages and is closer to being production-ready and in a business setting I would probably choose Nix for the project instead because of that, it also is compatible with macOS and Guix isn’t.
• The Guix package manager is source-based and the repos are committed to 100% free software which I really like compared to Nix which just throws binaries in their repos. However, this means that they need to package everything to work within their ecosystem as if they are packaging for an entirely different OS, and this is often very time-consuming, especially for packages with hundreds of dependencies. Combine that with the community being very small and niche, and repo under-maintenance is a very serious problem. Many core packages are outdated, which also seems like a security hazard. If you’re expecting to use a bunch of new Rust-hype programs or something that isn’t mainstream, they probably aren’t there (you may find them in an obscure third party repo however). Some core libraries made significant changes to their build process when they updated that haven’t made their way to Guix so they may be stuck on an old version until someone decides to update it. If there’s a package you need, expect to either package it yourself or download it with a different package manager like Nix or Flatpak.
• Most modern hardware requires proprietary blobs and you’ll need the nonfree Linux kernel from the nonguix repo. SystemCrafters has an installer image that comes with that IIRC.
• You may be interested in an “Erase Your Darlings” system configuration (do not save filesystem state to disk except for files/folders explicitly opted-in, requires even more upfront configuration but helps ensure reproducability). Nix has that built in. Guix doesn’t, but if you fuck around enough with the partitioning you can get it to work. I have a setup with BTRFS and subvolumes that took me a week to figure out and I had to do some hacky setting to make it work correctly with Grub. Also it’s more difficult to do when you don’t know how Guix’s file structure is laid out or are unfamiliar with the tooling and configuration language, there aren’t really any good tutorials on the internet for it either so lmk if you need any help (it doesn’t have disk encryption however since it is on a VM).
• If you want to make sure your system stays pinned to specific software versions, the way I do that is I have a channel.scm which has the channels like normal. Using the just command runner, I have a Justfile in the directory where I store my configuration. just update runs guix time-machine pointing to the channel.scm which pulls the repo’s updates then after the -- has the command that prints the channels with the specific commit to channel.scm.lock. For every other guix command, such as the reconfigure command, it uses guix time-machine pointing to channel.scm.lock then the command I want after --.
• Flakes is probably the most hyped feature about Nix, which instead of using a central repo for all software lets each project turn their git repo into a source for the package manager which can point to other repos it depends on. Guix doesn’t really have this feature, but since its main goal is creating an ecosystem of completely free software, I would argue that the centralized approach is better for this project since it helps GNU achieve this goal and provides guarantees about the freedom of the software and the packaging quality. Guix also makes it easy to create your own repo for packages or turn your project into a repo for a package, but it can’t refer to packages outside of the repos that are listed as sources on your local setup so it isn’t really flexible like Flakes.
• It also uses Shepherd for its init system which uses the same configuration language as the rest of the system. Compared to systemd I am not sure which is principally better, however it provides an additional roadblock to packaging software since most stuff is designed around systemd-based distros.
• This project is niche and has very few resources for help aside from the documentation, the source code (there seems to be quite a bit of undocumented stuff so you’ll probably end up browsing it sooner or later), IRC/mailing lists, SystemCrafters, and a few random blogs or git repos. ChatGPT fucking sucks at Guile and it spits out code that is about 80% incorrect so actually learn Guile and don’t use ChatGPT (sometimes it gets the parenthesis wrong too which is kindof hilarious).
• Setting up Emacs, a local SMTP server connected to your email for git, and a CLI password manager will probably be helpful.
• Have a copy of Guix cloned on your computer so you can browse around and see how stuff works (especially packages and services). It’s the same language as the system configuration language which is helpful. The documentation also has a guide to set it up for contributing which you may be interested in at some point.
• The contribution process is weird, it uses a lot of command line tools which I kindof like but it also has a learning curve which doesn’t help with the contributor shortage. Also it seems like a lot of patch requests get ignored and in some cases how to contribute is confusing. I was trying to contribute a Rust program once but it added hundreds of libraries and when I submitted it months ago it got ignored so I don’t know how I am supposed to contribute these sort of programs and the mailing list/IRC didn’t give me much advice either.
• For finding packages, there’s https://toys.whereis.みんな/ which shows stuff from nonguix and other repos you’ll probably want.
• For making your own packages, the guix import feature can be helpful and works nicely with Rust, especially if the program you want is in crates.io in which you can put it in your packages repo very quickly.
• For using Guix for software projects, there aren’t a ton of libraries packaged so you’ll need to see if your language is supported by guix import. The Node.js ecosystem is allergic to FOSS so it might not work very well with Guix (there are barely any Electron programs packaged outside of nonguix also).
• guix profile and guix home are confusingly different. One uses imperative install commands and the other uses a declarative configuration and they install into different directories, so if you remove a program from home but it’s still there it may still be installed in profile.
• Most packages should be installed using guix home and don’t need to be installed systemwide. It also provides powerful containerization/environment management tools to isolate installs efficiently.
• For server stuff, Shepherd has a sandboxing feature I’ve experimented with a tiny bit that isn’t well documented (if at all), I haven’t tested it in a while though but with it you don’t really need to containerize stuff. I haven’t figured out how do manage the networking correctly but there’s probably ways to do that as well.
• For servers, trying to package Node projects that aren’t in a single binary sucks.
• For desktop usage, I would recommend installing Guix Home on your current distro first and experimenting with that before doing a full system install (which is what I’m doing right now since being on a Macbook adds additional complications). You can do the same thing with Nix home-manager also.
• Guix and SELinux don’t really get along, on Fedora you may need to disable it (I don’t know how to use it correctly with Guix) which weakens security (which on Linux security kindof sucks). This is a problem with Nix as well.

To address your points:

The Debian/Fedora based ones seem to be fairly slow to update and so they have out of date packages, which sometimes is ok, but sometimes if they are too out of date I have to compile it from scratch.

Fedora is way more up-to-date than Guix is. Also Guix is source-based so it may end up compiling stuff from source automatically. You can install Nix though if you need it which looks a lot more up-to-date.

I end up spending a lot of time configuring stuff that isn’t built in

You’ll be spending a lot of time configuring stuff with Guix as well. However the declarative style makes it a lot easier to track and maintain.

having stuff randomly be broken after an update

Libcamera broke pretty recently on my Guix install which broke a ton of programs although it might be fixed now. If that happens though you can revert to your previous configuration or pin the repo to an older version until it gets resolved. Normally packages are checked when they are updated though to ensure they don’t break stuff.

I don’t have a lot of time to mess around with configuring stuff all the time.

You’ll need to spend a lot of time learning stuff since there’s very few tutorials on the internet.

Ideally I’m looking for a distro that works well with my old-ish hardware (with NVIDIA support unfortunately)

IDK if nonguix supports NVIDIA or not but it might be a problem.

if the library is designed to use like ‘pip’ or ‘bun.sh’ or some built in package manager

You can still use other package managers, but you can’t use them to package the program specifically for Guix. You may have luck using guix import instead however. Also bun.sh is an example of a non-mainstream program that probably isn’t in the Guix repos.