If you think about it Kubernetes concepts, the control plane is the API server and the data plane are all of the "kubelet", or worker, nodes
As soon as we make any request that goes over a network, we need to make sure that connectivity cannot be disrupted and that observability is in place. LinkedIn famously wrote a "smart" client to do that in Java, that every team must use and they keep maintaining over time but that limits them in adopting non-JVM technology in the organization and creates technical debt over time.
These are being slowly replaced with other components from Spring Cloud or Resilience4J: https://medium.com/netflix-techblog/netflix-oss-and-spring-b...
Disclosure: I work for Pivotal, but not on Spring.
I have Consul going, and making decent use of it for discovery, and have a feeling that Consul Connect may be a half-assed version of what you're describing; but I don't hear of many people using it.
The early service meshes were all built on top of Kubernetes, due to the fact that k8s/etcd is an easy platform to build control planes on top of (SD, networking, etc. already done) but very few large companies are ready to move everything over to Kubernetes.
However, the one thing that every service mesh promises is that the clients don't need to do anything. Except that they do. End users need to rip out functionality that is coupled already tightly to the application, such as authentication, "smart" routing and metrics. They need to orchestrate tracing to pass on the headers (how do you know what routes in your application were bad if all you have is a black box!). It needs to play nicely with already built in enterprise wide things.
I'm not sure that I'm sold on the universal service mesh unless you have a high level of engineering talent. The benefits are immense but don't expect to see universal service meshes* running at enterprisey companies any time soon.
* Universal means the entire company is governed under a service mesh, not the POC running on 3 servers for a random team :)
If Kuma gains traction, they can later offer additional capabilities in Kuma to swap Envoy with Kong (their API gateway) as my guess is that Kong API gateway is their cash cow at the moment. (of course they can potentially make money from Kuma via enterprise support, training, etc if Kuma goes mainstream).
These are purely my guess. From a user point of view, not a bad idea having Kuma in addition to Istio and other open-source/commercial alternatives.
Good luck with Kuma!
If nothing else, looks like they're both built around Envoy.