Nim is great, and I use it (in production), but I know exactly why it isn't as popular: Nim is fucking huge.
Most programmers I know don't even know what a pragma is; Nim uses them extensively. Nim has types, objects, is low level, can be compiled to shared objects (something that didn't come out to Go until 1.5), macros, generics, templates, oh and it compiles to both C and JavaScript (and C++, and Objective C in case you need easy bindings for those), dynamic dispatch, mutually recursive types, pointers, named arguments, tricky hash tables, procedures that look like functions or methods (whichever suits you), and an irrelevant casing (spellLikeThis is the same is spell_like_this - case only matters for the first letter and underscores don't matter), and many more.
All of this on top of a hyper fast (~2x the speed of Go) compiled language.
Most other very complete languages are not compiled so you can kinda muck around in a repl and use introspection to figure out whats going on. Nim isn't like that. You need to think and figure things out when you're first learning it. Furthermore Nim isn't yet at 1.0 and lacks its killer library. Go and Rust are easier to get started with because they are simpler languages. They are easier to teach and easier to write documentation for.
Nim kinda reminds me of Ember or Rails or C++(see note): Huge, but worthwhile to learn because you'll never feel constrained by it. I highly doubt it will ever be as mainstream as Go though. I've generally found that most people are too lazy to learn harder languages / libraries.
Note: I do not like C++ for many reasons. The tooling is crufty, syntax is awful, impossible to reason about a codebase unless its picked a subset of C++; but the one thing I'll grant C++ is that you can always eventually get what you want done.
What you've just described is a hodgepodge of stuff thrown together. That's a lack of language design with a surplus of features. My readings on older reports for language designs showed the art was figuring out just how much power to include in the language & keeping it all consistent/sensible. One can overdo it.
An example of a clean, carefully-thought language that's low-level, consistent, and very powerful is PreScheme:
Modula-3, a C++ and Java competitor, was another where they made careful tradeoffs of features, safety, compile speed, run speed, and ease of learning/reading.
There's also some dialects of Haskell and ML focusing on system level. Didn't hit those levels of maturity though. What I'd like to see is someone take the Nim tech, subset it, change inconsistent stuff to be consistent... basically clean it up into a coherent picture... then deploy that as a new language. It could be pretty awesome if it happens. Right now, it's too complex and incoherent except for people, as you said, willing to do a huge learning curve.
Note: Nim is so huge now that it might be easier to add Ada static checks and Rust dynamic/concurrency checks to PreScheme instead of fixing Nim. You'd have a low-level, safe LISP. Put a 3GL front end on top of it for more adoption. That's what Julia people did.
Well I don't have a negative view of Nim in general, and I wouldn't describe it as a hodgepodge. I would describe Nim as a language that doesn't hold you back and doesn't save you from yourself. Personally I refrain from using most of the complex stuff, but when I need it I love how it is there for me. For example, the shared objects make it very easy for me to just roll things in Nim then link them to Ruby through the FFI.
Will your average developer need these features? No. But the average developer writes ASP, PHP, or JavaScript. I'd rather be formidable even if it means doing the work.
"and I wouldn't describe it as a hodgepodge. I would describe Nim as a language that doesn't hold you back and doesn't save you from yourself."
That's kind of vague. When I say hodgepodge, I mean they threw in all kinds of capabilities into the language without integrating them into a consistent whole. The examples I gave leave no surprises. What you see reading others' code is even expected. You could do about anything in a variant of PreScheme that you could do in Nim given almost any language feature gets ported to a LISP as a library. Except, it's all consistent in its style, syntax, and techniques for doing whatever it does. Nim seems to lack that very-significant property that affects uptake, ease of formal analysis, and maintenance burden.
So, the language is powerful. People are doing neat things with it. Just lacks design traits that have historically been important for programming languages in terms of getting and keeping developers/users.
Most programmers I know don't even know what a pragma is; Nim uses them extensively. Nim has types, objects, is low level, can be compiled to shared objects (something that didn't come out to Go until 1.5), macros, generics, templates, oh and it compiles to both C and JavaScript (and C++, and Objective C in case you need easy bindings for those), dynamic dispatch, mutually recursive types, pointers, named arguments, tricky hash tables, procedures that look like functions or methods (whichever suits you), and an irrelevant casing (spellLikeThis is the same is spell_like_this - case only matters for the first letter and underscores don't matter), and many more.
All of this on top of a hyper fast (~2x the speed of Go) compiled language.
Most other very complete languages are not compiled so you can kinda muck around in a repl and use introspection to figure out whats going on. Nim isn't like that. You need to think and figure things out when you're first learning it. Furthermore Nim isn't yet at 1.0 and lacks its killer library. Go and Rust are easier to get started with because they are simpler languages. They are easier to teach and easier to write documentation for.
Nim kinda reminds me of Ember or Rails or C++(see note): Huge, but worthwhile to learn because you'll never feel constrained by it. I highly doubt it will ever be as mainstream as Go though. I've generally found that most people are too lazy to learn harder languages / libraries.
Note: I do not like C++ for many reasons. The tooling is crufty, syntax is awful, impossible to reason about a codebase unless its picked a subset of C++; but the one thing I'll grant C++ is that you can always eventually get what you want done.