What do you mean with "stateless" here, and which of those meet the stateless criteria? I have a hard time imagining any of those without state.
Deployments of server applications do usually involve some inherent state, like the contents of a database or the fact of which services are running. In that respect, some deployment tools in the Nix ecosystem are not isomorphic. But the software management and package management components, for example, are declarative without involving any reasoning about the current state. It is in that sense that those components are 'stateless' in a way that the rule of thumb proposed in the GP is not.
This is an option, but it is certainly not a requirement. If I say "I want cheeseburger", it is irrelevant to me if the cheeseburger is made from scratch or had been partially assembled ahead of time.
You are concerning yourself solely with configuration that can be generated not only declaratively, but also fully deterministically, but configuration systems can indeed exist where the environment isn't sufficiently deterministic. In such cases, taking the current state of the world, the user's request, and then determining the appropriate (and preferably minimal) actions to take to harmonize those without having to have them specified by the user is a declarative approach.
For example, I can go to the AWS console and turn up a job with a set of parameters, or I can have a configuration file and a daemon and if
{
cpu: 5,
mem: 20,
image: "my_docker_url",
}
is present in that file, I can then assume a job meeting those specifications exists, and if not present the job will not exist. The daemon might do this by shutting down all the jobs and starting new ones every time the file is parsed, but that is probably not great. Approaches that only restart changed jobs, or which can dynamically resize jobs that support such things might lead to significantly better performance of th esystem as a whole.
Whether the system charged with realizing desired states reasons about the current state is actually not relevant. Declarative systems work by generating the desired state 'from scratch', often with some kind of efficient cache.
A declaratively styled configuration system which still works by transitioning the system between target states statefully is still subject to the same problems as imperative configurations, but they're abstracted away from your field of view, as long as things sort of work.
A stateless approach, also typically (always?) configured in a declarative style, actually addresses these problems in a principled way. For an example, consider NixOS vs. Puppet, Chef, Ansible, etc.: https://www.domenkozar.com/2014/03/11/why-puppet-chef-ansibl...
I like that essay's term for the paradigmatic differences, rather than the merely stylistic differences between imperative and declarative configurations: convergent vs. isomorphic.