I mean, I get the appeal of using a broader term.
But “declarative” by itself does not capture everything. Plain configuration files are declarative, and so are things like SQL. Likewise, “code based” could describe a package manager built around an unrestricted imperative language, which would be a poor fit for a reproducible declarative system unless the language were heavily constrained. Not that I’d stop anyone from trying, just I’d probably not use it!
The functional and purity related aspects are not incidental implementation details. They are a large part of what makes NixOS and GuixSD work. Configurations can be composed and evaluated as values, dependencies are explicit, and results are not supposed to depend on hidden state or arbitrary side effects.
So yes, something similar could be built using a language that is not usually called functional. But it would either need to reproduce many of the same functional and purity-oriented semantics, or it would become a substantially different kind of system that may no longer feel much like NixOS or Guix System. And I think without a somewhat pure model getting any of this to work at scale is really hard and brittle to maintain.
So I think “functional system distribution” still identifies something more specific than merely “declarative” or “codebased”, something load bearing for what makes these systems special.
Of course, Nix(OS) essentially has counterexamples where any and all of these rules can be broken, but those are more divergences from the actual paradigm, not really intentional parts of how it works, so I don’t think it defeats the point.