As those are built on Wolfi by Chainguard I would not use them in production. They restricted already their own images for only paid customers and also recently limited OSS entirely on Wolfi. So there is no guarantee how long the packages may be available for non paying customers.
If you depend as a non paying customer on Wolfi you should avoid it now really. They don't care about any Issues / Pull Requests anymore. Even when you try to fullfil the new requirements for Contributions your requests get's closed by automation: https://github.com/wolfi-dev/os/issues/77994
I agree with you, when you have the knowledge and have fun doing your local devops, you can skip such software.
We have a lot of users (devs, designers, qa) which don't care about their local setup. Installed anything using a random tutorial and never change a running system. Last weeks, we just updated our node constraint from 16 to 18 and many users were lost to install the right version (only ~18 was allowed). So it's for us a huge benefit to be able to declare the environment and share it to all users who don't care about their setup and just wants to do their work :). I hope you got my point :)
Why stop there though? You can simplify the whole build and bundling process with Nix. Remove the Composer, npm, Docker, and let it all be in one declarative language, Nix.
Through it has similar drawbacks as using docker-compose with docker.
As far as I know there is currently no rootless way on Linux to setup custom internal networks like docker compose does (hence why podman-compose doesn't support such things).
There definitely is a way as creating custom networks works perfectly fine with rootless docker. I'm surprised if podman doesn't support that since it uses rootlesskit (same as rootless docker) which does the heavy lifting for rootless networking.
An Ansible playbook with the podman_container module is my go-to. It's not as easy because it's less magic but it's also less magic which I count as a win.
With docker all container have their own ip address and (potential) internal DNS name.
But this can't be done rootless.
So with rootless podman all container map to the same ip address but different ports.
This is for some use cases (e.g. spinning up a DB for integration testing) not a problem at all. For others it is.
More over you can run multiple groups of docker containers in separate networks, you can't do so with rootless podman.
Through you can manage networks with rootfull podman (which still has no deamon and as such works better with e.g. capabilities and the audit sub system then docker does).
Through to get the full docker-compose experience you need to run it as a deamon (through systemd) in which case you can use docker-compose with podman but it has most of the problems docker has.
