The key difference is that systemd is system-wide orchestration, and docker-compose controls a specific set of containers connected in a specific day, and likely otherwise isolated from the system. The latter allows to "ship" entire configurations that work together, as one unit.

I think that existing tooling on nix environments can work much better than docker compose to aggregate a set of containers and resources.

Setting resource limits using cgroups, isolating users/paths/networks using the capabilities of systemd and all together used from a common shell script seems more expressive and more versatile than using docker/docker compose and requiring an extra daemon to deal with everything.*

More expressive? I think so too. Less convenient? I think so. Sadly history shows that convenience wins.

If you have to roll your own, you now own it. This should be a huge bar, and better isn’t enough.

This is the same flexibility trap as C++ build systems. Whereas in Cargo, adding a dependency is a single line.

Knowledge and practices that are pulled from the ecosystem compose, and can be ephemeral in ways that hand rolled solutions are not.

The thing with docker-compose.yml is that it is well known, well documented and relatively easy to learn and get running even for more complex configurations.

I would not want to go through that common shell script for every new project because it would probably look very different from project to project.