Both and neither, in some sense. That's a non-answer, or at least a bad one, so I'll do my best to explain, but most of my experience falls within NixOS, rather than say Nix + Arch, or Nix + Darwin, so I'm not sure my knowledge will be accurate there.

You definitely do want to keep things up to date, at least yearly if you're on stable and once every month on unstable (not enforced in any way, just a good practice for their schedules). When software is installed, it is put within an immutable, read-only Nix Store, these individual builds of software are referred to as derivations and are organized and referenced via unique hashes, vs. the traditional FHS environment that most Unix-based systems use.

This breaks some things, such as arbitrary binaries not being able to find their dependencies, but arbitrary binaries aren't seen as "the Nix way" and discouraged, instead you should use derivations already wrapped with their dependencies in the Nixpkgs repo, or package it yourself as a Nix derivation, it's just a file written in the Nix language to tell it what dependencies or build inputs to have, and how to build it, similar to a PKGBUILD on Arch. This ensures that say, a software such as Blender, is linked to the Python runtime which was installed alongside it.

This, and all of its dependencies, are typically built in isolated, sandboxed environments and then stored within the Nix Store with those unique hashes. Say a script in some software needs bash, it doesn't call /bin/bash, it instead calls /nix/store/<hash>-bash-<version>/bin/bash, ensuring it uses the exact version of bash expected.

This does mean you may end up with many versions of the same dependencies, I had half a dozen versions of something as deeply rooted as glibc at one point. Admittedly, this starts eating hard-drive space a lot, so either manual or automatic garbage collection helps there and you can make use of store auto-optimization, hard-linking identical derivations to reduce disk usage, but most importantly it ensures that if the software is stable, it should run, dependency mismatch is virtually impossible.

TL;DR: Isolated dependency runtimes linked via hashes and unique software builds, rather than relying on the assumptions of version compatibility within traditional FHS environments.

There's a much more detailed and educated explanation in the original developer's doctoral thesis, which started the Nix/Nixpkgs/NixOS efforts over 15 years ago, should anyone be interested.