From what I've seen reviewing k8s clusters some of the items in your "sensible measures" list aren't considered easy to manage and deploy.
In particular good RBAC design, that doesn't end up leaking information across namespaces, PSPs that are flexible enough for developers but strict enough to prevent privesc and strong network policies present challenges.
For those, less mature, organizations, a solution like this might present an easier option.
I don't want to gatekeep, but in my opinion organizations that can't afford to set this up correctly _likely_ shouldn't be running k8s in the first place.
From my experience with companies that haven't done their organizational or engineering homework: half-assedly deploying Kubernetes ends generally ends up being an unmaintainable disaster.
One of the high-return-value aspects of k8s is having little clusters available to multiple tenants. Without this in place k8s really stops making, being too complex for its actual usecase - so you might be much better of using something simple like Nomad.
Whether they (the user) should (run Kubernetes) or not, there are many systems and products out there that are meaning to make Kubernetes as accessible as possible.
In fact, the goal of many solutions (GKE, AKS, EKS, etc) is meant to be "We managed the entire cluster for you, just deploy your workloads!".
In many situations, if a company is running a single application in their cluster, many of the these management aspects (networkpolicies, quotas, etc) are not at all necessary for their use-case.
You say they shouldn't be running k8s in the first place, and I half agree with you. They don't _need_ to be running k8s. Large platforms have done a lot of work to make "Run in a Kubernetes Cluster" as approachable as "Run in Heroku".
Regarding Nomad, sure, but if someone hasn't done their engineering homework, the chance that they are even familiar with Nomad is slim (no offense to Nomad)
In particular good RBAC design, that doesn't end up leaking information across namespaces, PSPs that are flexible enough for developers but strict enough to prevent privesc and strong network policies present challenges.
For those, less mature, organizations, a solution like this might present an easier option.