The other is "we don't need Docker because we use tools like buildah, img, or kaniko to build OCI containers, our devs use podman, and we run this stuff in prod on a someone else's k8s PaaS that under the hood is backed by containerd."
Many are anticipating scaling problems they'll never have and wasting a lot of time, effort and money in that process
Yes, it would be possible to get sucked down a rabbit hole with over-emphasizing scaling, clustering, whatever upfront, but IMO these tools are now mature enough that it's a reasonable workflow even if you're just deploying a single instance of a container with one statically-linked binary in it.
People are also totally right to question why some new fancy tool is needed when the old way works. Its best to just view all these things as tools at your disposal rather than necessities.
Better to think of these titles as "When you might need Docker" and "When you might not need Docker" so you can consider the tradeoffs rather than interpret it as a blanket statement, Docker is good/bad.
God knows how much "don't need JavaScript" gets posted...
Red Hat OpenShift also switched from using Docker as its runtime with OpenShift 4 in 2019, though it was in favor of CRI-O rather than containerd.
If a critical mass of kubernetes deployments switched from containerd to cri-o, that would be more problematic for Docker, but that seems unlikely to happen. Openshift to my knowledge is the only major kubernetes distribution not based on containerd. At this stage of the adoption cycle, cri-o is unlikely to be more than a distant second to containerd.
I read it as a typical "We don't need [Complex Tool] because we don't have [Complex Tool Solutions] problems". Not trivializing it, I think those articles are valuable hype-free analysis of the latest tool-of-the-day. "They don't need Docker" and "We absolutely need Docker" are non-contradictory.