> Can someone elaborate on why Nomad should be avoided?

The answer is, as always, it depends on your use-case. I'm not personally not a huge fan of Nomad for reasons I won't go into because a) they're irrelevant because opinions, and b) they're probably outdated. However, to say "it isn't much better" is very vague and extremely subjective. I don't really know what OP means with it, but consider the following things I know about Nomad vs Kubernetes:

Kubernetes has many more features that you or your users don't have to deal with (in terms of setup). Obviously that brings in complexity that Nomad may not have to deal with. This also means that some features may need to be supplemented using other software, which otherwise means learning those other software and having different interfaces to manage it. Kubernetes on the other hand, provides all of these features using the same interface. Obviously this also means with Nomad you can add some of these features as you need them over time, instead of having it all at the beginning regardless of whether or not you need them. Some features I can think of: secrets management*, load balancing, config management, service discovery.

Kubernetes has a much bigger community, many more tools you can just plug and play. The relatively recent phenomenon that is Kubernetes Operators is just awesome and makes running software a breeze. Software that otherwise requires a lot of knowledge to run.

Kubernetes only does Linux containers, compared to Nomad that has support for just about any thing you can throw at it (Java, containers, plain binaries), and it has first class Windows support (via Windows executables). Last I checked Windows support for Kubernetes was still in its infancy.

In terms of support, with K8s you will need to get a third-party to give you support, whereas with Nomad you can get support directly from Hashicorp.

Nomad requires a Consul cluster, at least last time I looked this up, though as I understand this, HC was working on this in the past year or so, so this may not be accurate any more. Kubernetes uses etcd internally, which itself takes some understanding.

Lastly, Nomad will likely lead to vendor lock-in. Kubernetes can run just about everywhere including on-prem, all major cloud providers, and even at the edge (see KubeEdge). Chick-fil-A famously runs Kubernetes on Intel NUCs in all their stores. I'm assuming there is nothing stopping a Nomad cluster being run at the edge, but I suppose it's not been proven yet.

* note: secrets management is a bit of an overstatement for Kubernetes. By default it is base64 encoded "secrets", and the only thing preventing one from accessing the secrets is ACLs, but if you have access to the underlying etcd cluster, it's game over. If you want proper secrets management (i.e. encryption at rest and/or in transit), you'll need to integrate it with something else such Hashicorp Vault (the most advanced option), or Mozilla SOPS.