Consul/Nomad deployment is easy and operation is a breeze. As the sole ops person at my company, Nomad has made it possible for me to scale our infrastructure without an entire team dedicated to it.
I'm not saying that it's better than K8S, but for a small team who wants to focus on building things, it's an amazing time saver. Obviously, read the docs and make your own decisions, but there is a definitely an infrastructure void that Nomad has filled perfectly.
I'm skeptical that anything allowing flexibility in this space can ever be that simple because the domain is actually pretty complicated. Networking, secrets, scaling, healthchecking, deployment strategies, containerization -- you need to know something about all of these before you can use Nomad or Kubernetes.
IME, a lot of complexity, in kubernetes land, also comes from kubernetes being highly opinionated. Whenever your needs don't match kubernetes' opinions, you have to fight it. To give you an example, service versioning is not something kubernetes knows about. If you need it, you need to add it manually. You can easily automate this with consul, and make applications unaware of service versions. Reciprocal trust verification between ... things that communicate is another. Kubernetes provides nothing. If someone manages to inject a pod into your namespace, and randomly starts replaying requests, there's no automatic way to verify the caller's identity - you have to do this manually, at the application level, using a custom sidecar (if you're lucky, your service mesh has something to help you). If you use consul with nomad, you get these things out of the box.
I believe your life is simple now because what you manage isn't overly complicated. Once you have thousands of distinct deployments, versioned, across several clusters, and thousands or even tens of thousands of pods running in tens of data centers, life with kubernetes becomes a lot more difficult. Of course, you can still manage, by automating everything, but automation, at that level, with kubernetes, is not an easy thing. Or at least that's my experience.
If you're doing your own bespoke ops or you need to own more of the stack, then Nomad is a powerful choice.
Is it, really? It feels like it is it's main disadvantage, in the sense that Kubernetes is a first-class citizen offered by practically all major cloud providers, while Nomad... Is anyone actually offering Nomad at all?
Nomad, on the other hand, is pretty simple and easy to run, and a single binary. There's probably no benefit to having a managed offering.
That said, I wouldn't be surprised if HashiCorp add Nomad to HashiCorp Cloud Platform, which currently lets you deploy Consul and Vault to cloud providers via their system.
Which is to say it's useful enough to a large amount of people to make it viable as a product offering. Nomad would fail as a managed offering here like like Deis, Flynn, Convox and probably 100 other container management platforms that came before.
As a niche tool to manage sub-1000 boxen it's probably ok. But k8s has won the greater war.
Disclaimer: Worked on Flynn, still run it for my own personal stuff by $DAY_JOB is all k8s.
Your enumeration of the managed things is very particular, in that it includes only stores. There's a reason for things that have keeping persistent state as their reason to exist are managed: reliably maintaining persistent state in the cloud is a lot more difficult than reliably orchestrating things that just have to run.
Managed _something_ does not mean it's "mind-bendingly complex", but rather that people don't want to take care about it and focus on their own stuff like building applications.
My actual need is that I deploy my application and I don't care where or how it is running. Most of people should not even think about running k8s on their own. That should be job of a service provider and there should be service provider for running "Nomad".
There are some specific places that k8s can shine, but easy scaling(1000 nodes +) and low management overhead isn't one of them.