I like podman because rootless and daemonless are built-in and default. Yes, it can be done on docker, but you have to do a bunch of shit to get it set up.
You could create the alias alias docker="podman" and 99% of the time, you won't even be able to tell the difference since podman is a docker drop in replacement. All the docker documentation applies to podman as well. But since docker runs as root by default, some edge cases might not work out of the box (like binding to a port on the host less than 1000).
Podman comes with some neat tools like being able to create systemd service files to start and stop containers as services.
To use docker-compose, you'll need some additional packages. That's probably the biggest drawback to podman imo. Podman wants to use pods instead of docker-compose, but I think they gotta take their heads out of their asses and just support the more popular format on that one. Not to mention docker-compose is just plain better imo. Easier to define, easier to understand, easier to modify. The list goes on and on.
I like the idea behind Podman, but it's not a suitable drop in replacement for Docker yet. Especially since it requires manual setup to auto-start stacks at boot, and can't import docker compose files easily.
Docker is easier to use, has many more examples and tutorials out there, and every project generally provides a docker compose file ready to go for quick setup.
Because the lxc way is inherently different from the docker/podman way. It's aimed at running full systems, rather than mono process containers. It has it's use cases, but they are not as common IMHO.
Did it sound cold? Because I didn't mean that, I just meant to actually answer the question from my PoV. Just for the record, I also did not down vote you.
So yeah, use whatever footgun you prefer, I don't judge :)
The Podman developers did contribute to Docker for a while before starting the project. Docker kept introducing issues and had some fundamentally bad design decisions that they didn't want to change.
At least try to look into the history of these things before making broad and easily falsifiable statements.
Takes 1 minute to write a non systemd startup script, come on.
I understand systemd "spoiled" people, but not having a potentially insecure always running daemon for no purpose at all (docker) beat the alternative for me.
Docker is a great choice with lots of good tutorials. I personally use podman since all my servers are now running Fedora server and podman is installed by default.
Podman is slightly better, but most tutorials are for docker.
So, podman if you're comfortable looking through docs, man-pages, scarce Internet resources, and trial and error for finding things out. Especially if you care about having better security with rootless mode.
Podman also has a different way for managing many containers at once, and the interaction between them.
I think k8s is a different beast, that requires way more domain specific knowledge besides server/Linux basic administration.
I do run it, but it's an evolution of a need, specifically when you want to manage a fleet of machines running containers.
I've tried Docker Swarm because Kubernetes seemed like an overkill for a cluster of 4 small-ish servers. There have been several issues (networking for example) that took me two days to solve - by reinstalling the machine completely.
There are some hoops and hurdles along the way, some command will just literally brick your cluster without any notice whatsoever (like removing the second manager, leaving only one and cluster stops responding, but you get no warning that's gonna happen).
Also secrets, where there is no simple way to manage them, or replace them. You can't just replace a secret, you have to remove and recreate it. Which means turning off the service or creating a new secret with a different name and do a rolling update, which is just annoying to do every time unless you can afford a robust CI CD pipeline code that does it automatically.
To be honest, some kubernetes distributions make the cluster operations minimal (I use k0s managed via ansible)!
Either way, the moment you go from N containers on one box to N containers on M boxes you need to start considering how to handle stateful applications, load balancing, etc. And that in general requires knowledge on a domain which is different from having simply applications wrapped in containers locally.
I use Docker and it works for what I use it so I have no need to change it, maybe if in the future I have the need to use podman I would consider to change. But right now I'm not interested.
I personally prefer podman, due to its rootless mode being "more default" than in docker (rootless docker works, but it's basically an afterthought).
That being said: there's just so many tutorials, tools and other resources that assume docker by default that starting with docker is definitely the less cumbersome approach. It's not that podman is signficantly harder or has many big differences, but all the tutorials are basically written with docker as the first target in mind.
In my homelab the progression was docker -> rootless docker -> podman and the last step isn't fully done yet, so I'm currently running a mix of rootless docker and podman.
I use podman with the podman-docker compatibility layer and native docker-compose. Podman + podman-docker is a drop-in replacement for actual docker. You can run all the regular docker commands and it will work. If you run it as rootful, it behaves in exactly the same way. Docker-compose will work right on top of it.
I prefer this over native Docker because I get the best of both worlds. All the tutorials and guides for Docker work just fine, but at the same time I can explore Podman's rootless containers. Plus I enjoy it's integration with Cockpit.