One interesting fact is that minikube actually used to be very similar to k3s. (I used to be a maintainer of minikube)
We called it localkube, and it was an all-in-one binary with features stripped out that ran the kubelet, apiserver, kube-proxy, etcd, and other components as Go routines. Eventually it had to be removed - upstream k8s was moving too fast, and there were fundamental issues that couldn't be fixed without large patches (TPRs, the predecessor to CRDs were one).
The problem with this approach is that it requires a ton of maintenance and there can be subtle bugs that come up.
The other distinction not found on this list is that only Docker for Desktop and minikube are cross-platform solutions. Running Kubernetes and docker on Linux is somewhat trivial, but managing a lightweight virtual machine and adding that extra layer of abstraction is what makes it really difficult.
Personally I think it's time for a Kubernetes fork. Let K8s get huge and change too frequently, but let's get a desktop/less-robust alternative going that doesn't change frequently at all.
The hope would be that we would stop trying to chase our tails keeping up to date with K8s, and instead we could maintain a more generic abstraction layer which could be applied to other PaaS/SaaS systems as well. You use the abstractions to separate the design from the implementation. The "desktop" implementation could be insecure, non-HA, non-robust, easy to install & maintain. The "cloud" implementation could be all the best practices. The containers would be the same, but the service definition, command-line tools, etc could all be different, and just be written to interface with the abstraction specification.
Obviously you still would need to completely test the hell out of the service in the cloud cluster before releasing to production, but the initial local development could be much faster when done locally in a simpler system. I think trying to replicate the cloud implementation locally is just asking for trouble, we know it will never match up.
> Let K8s get huge
Correct me if I am wrong, but I don't see trend that k8s is getting huge. In fact, I get a feeling that it is trying to be smaller. If you look at the release notes for each minor version, lots of in-tree features are being deprecated and users are being pointed to out-of-tree implementations. DNS, networking, metrics server, cloud vendor specific features(storage class, load balancers), container runtimes...just to name a few. And the community put great amount of effort to harden API machinery, to make it easier for 3rd parties to implement specific features for specific business.
This kind of gives me hope that one day I may be able to just run a vanilla k8s straight out of a release from github.com/kubernetes/kubernetes without any "batteries" as a platform, and I can later decide what I want to install, all by myself.