I'm using podman-compose for my homelab, which is obviously fine.
But even for small-scale single-node production use cases, I suspect that podman-compose with systemd doesn't have the same concerns as docker-compose does. Since you're registering the workload with systemd, it'll restart with the node as easily as any other service, and rootless containers are a big win for security.
Where you can't keep using (podman|docker)-compose is when you have to scale up a service beyond a single node.
You can keep using x-compose on several nodes, you just need e.g. ansible or salt on top of it. For many things this is still a local maximum compared to a K8s cluster or "just ssh in'.
For a lot of the services I'm thinking of for this case the scheduling may be across multiple nodes but it may not be flexible - e.g. this is my preferred way to run things which need guaranteed local iops. So Swarm maybe helps with service discovery etc. but its main purpose is lost.
I have a lot of complaints about Docker Swarm but they're either about its ownership issues or relatively minor (but - lots of minor) issues, if you want to use it it's fine. But you do still need an orchestration layer above it anyway.
But even for small-scale single-node production use cases, I suspect that podman-compose with systemd doesn't have the same concerns as docker-compose does. Since you're registering the workload with systemd, it'll restart with the node as easily as any other service, and rootless containers are a big win for security.
Where you can't keep using (podman|docker)-compose is when you have to scale up a service beyond a single node.