I work for a company that recently reconsidered our stance on OpenShift. Long story short, we looked at vanilla k8s rather fondly because of nearly all of the counter-points. The factor that brought us back to OpenShift was the secure-by-default aspect and that some of the training wheels (OCP console) couldn't be replaced by vanilla in a secure way.

Here's what we do:

- We don't use "develop on OpenShift" features like Eclipse Che or on-demand Jenkins nodes to build a project

- We don't use OpenShift-specific resources if there's _any_ alternative in the vanilla kubernetes resource definitions (e.g., use Ingress instead of Route)

- Use outside CI/CD to handle building and packaging of the applications, then deploy them with Helm like any other Kubernetes cluster

- Use the OCP console like a crutch of last resort, preferring `kubectl` whenever possible

All of this helps avoid vendor lock-in as much as possible while still taking advantage of the secure-by-default approach to a kubernetes cluster.

Talking with Red Hat engineers, it sounds like the OpenShift-specific things are contributed upstream and, while they may not become available by exactly that name and syntax, essentially the same functionality does come into vanilla Kubernetes. Routes inspired Ingress resources, for instance. The official stance is for OpenShift users to prefer the vanilla resources because the OpenShift-specific ones are intended to be shims.

(not a Red Hat employee, just work for a company that is a customer)