Looking at it from the consumer side and comparing like to like I don't feel its a _lot_ simpler. Task groups and pods, tasks and containers, config, networking, storage, it is all different on nomad but not, imo, tremendously simpler. That makes sense given the nature of the problem the systems are addressing. Over the last five years kubernetes has grown horizontally a great deal to encompass more and more enterprise features and use cases, and I feel in general this is a repeating pattern: a thing is created, it works well and becomes popular, more people use it and join the community bringing their own use cases, which drives the addition of features to the thing, which eventually gets complicated enough that people are attracted to a new thing that does largely the same stuff but hasn't had a lot of the new features added yet. Rinse and repeat.
On a somewhat unrelated note: I'm not very attracted to server-side features for tracking and manipulating versions of deployments and their history. I'm a fan of git ops, and what I want out of the server-side runtime is reliable, fast reconciliation of the infrastructure state with the release branch in my repo. If I want to roll back I would much rather revert in git and redeploy. It seems troublesome and error prone to rely on a cli command to force the server side state to a previous iteration that is not in sync with what master in the repo says should be the canonical release version. Interested in others' thoughts, but maybe its a separate topic.