That's not what "functional" is referring to in this context; the builds are (mostly) deterministic, so given a set of inputs (configuration settings, version preferences, extra patches, etc) you're guaranteed the same build artifacts (regardless of the current state of the system). Transactions and checkpoints don't imply determinism, and vice versa. Without determinism, the presence of other installed packages could impact subsequent builds (regardless of transaction support). Also, if the package language is imperative, you could change the values of inputs after producing build artifacts, and your system would become inconsistent.
So functional here is referring to the fact that the package language is functional, and the build system is deterministic.
There's no reason to want a package manager to be non-deterministic (i.e., unpredictable). I gather that functional is meant to encompass more than those two properties; I just didn't want to list them all.
What bugs me a little is that there are Programming Languages folks that are into functional programming and Computer Systems folks that work on things like filesystems. I liked Systems in college. It seems like the PL camp has somehow found a way to rename systems concepts that already had names and call them functional.
So functional here is referring to the fact that the package language is functional, and the build system is deterministic.