If there's basically no security, it would be more honest to do away with the "docker" group and just say that you need to give root to all docker users.
Creating a docker group and adding the user to the docker group to avoid sudo is more of a convenience thing, and the implication seems to be well documented now - https://docs.docker.com/engine/install/linux-postinstall/
so if someone sacrificed convenience over security, I think the authors can't do much.
Also I think there's no such thing as secure vs non-secure product, instead its levels of security.
I mean they could ship rootless docker by default, like podman defaults to rootless (or other by now possible more secure non default setups).
Also if you care you probably want to combine rootless (or non-rootless but still user namespace using) docker with a linux secure module setup like SELinux, as it can make security vulnerabilities in rootless docker (and well docker in general) much harder to exploit.
Upstream doesn’t support that configuration as default and it will likely break all the docker tutorials online that assume a rootful daemon. (A quick example: google “Jenkins docker integration” and it will likely tell you to pass through the docker socket)
Hence package maintainers don’t want to take the burden of maintaining that.
also to quote that documentation:
> By default, the Docker Pipeline plugin will communicate with a local Docker daemon, typically accessed through docker.sock.
which means that iff they do it right it will just work frictionless. Rootless docker still has a local socket and in a proper setup $DOCKER_HOST is used to point to it. $DOCKER_HOST is used the docker command, and any other application which communicates with the docker socket instead MUST handle it or it's a pretty big bug even in the absence of rootless.
And again you don't need rootless, you can also configure user namespaces with rootfull docker. Which isn't fixing all issues for all use cases, but fixes the ones which are an security issue for Jenkins.
In general the only place where a default docker setup can be security wise acceptable is where it's acceptable to always explicitly use sudo, e.g. no developer setup. Which mainly leaves use cases like using it for long running manual managed services, but then using podman instrumented through systemd (systemd directly supports OCI images as services) is still most times preferable.