It is not innacurate at all. First because OpenShift does not use podman to run containers, as upstream Kubernetes does not use Docker anymore. The needs and requirements of a general-purpose local container engine are different from a container engine for Kubernetes.
JFYI OpenShift runs CRI-O as its container engines, and upstream Kubernetes offers containerd as an alternative.
Local container engines are standardized by the OCI specification. Kubernetes needs are dedined by the CRI API. Many features available from OCI, thus available from podman, docker, and other container engines, are not available from CRI.
You can configure OpenShift to run a pod as a specific user, as you can with Kubernetes, but that comes with securty concerns because containers and pods are not isolated, by Kubernetes and the CRI, at a host level.
Kubernetes is not able to use uid namespaces so different pods, from different namespaces, that share the same uid actually share it at the host level and that increases the potential impact of a container engine leak where a container gets access to its host.
With any Kubernetes it is a security recommendation that you run pods with different uids than each other. OpenShift just provides mechanisms to enforce that by default while upstream Kubernetes does not.
This is not hypotetical, there are a number of CVEs that affect a "vanilla" Kubernetes deployment, and many products such as Rancher and EKS, but do not affect OpenShift under its default settings only because OpenShift will not run pods as the uid specificied on their container images.
This is so true that what we consider nowadays as good qualtity container images and helm charts, such as the ones from the Bitnami community, don't require that you run containers with a fixed uid and they work as-is with OpenShift.
If you considered all risks and implications and wish to run a pod with a specific uid, you can take explict action to allow that and manage that pod as an exception. Learn about configuring SecurityServiceContraints (SCCs) on OpenShift. With upstream Kubernetes, you can do that with no explicit action and unaware of the risks, with no assessment of whether the risks are acceptable or not to you.
Outside of Kubernetes and OpenShift, running rootless containers properly require knowing how uid and gid mapping affects the inside of the container and its host. Uid and other namespaces do not come free and seamless. This is tricky to get right if you expect a container to use a volume from the host or different networking settings.
It looked easy for rootfull containers because the container engine operatated under no constraints. For rootless, the invoking user and the container engine have to consider many special cases and usually the easiest path is just to configure the container image to work well as any uid instead of a fixed one, which makes the image automatically "good" for OpenShift.
