Depends on how you look at it.

Systems that don’t try to hold your hand all the time are “automation friendly”, I think. With those systems, you can install a package (meaning: download a tarball and extract it, nothing else) and then you can push your config to the system, start the daemon, done. OpenBSD, Arch and Void (I think) are good examples of that. They are in contrast to systems which do things like creating default configuration files when installing a package – because that means you have to clean up those default configs before you can push your own configs.

So, essentially, systems that are plain stupid and don’t really do anything on their own are good for automation. At least if “automation” means using something like Ansible or BundleWrap.

Or you can look at it from a different angle: Maybe the system should do as much as possible on its own. Basically, it would have the config management system builtin. So, dunno, maybe boot the system with a kernel parameter like “dhcp=true config=https://example.com/webserver-1.json”, then it asks for an IP via DHCP, fetches the config (which would be something like a short abstract description of the system as JSON/YAML/whatever), and configures itself. That would mean you could install the exact same OS image everywhere, just change the kernel parameters a bit.