That is definitely unfortunate, but Nix is such an obvious improvement on the standard Unix way of "Just mix all the files into one big /usr soup" that it seems silly to not do it because some programs need a bit of hackery to get them to work.
Hopefully one day Nix's approach will be popular enough that GCC or Clang will be changed so that the hacks aren't needed.
Having just learned about Nix a few weeks ago, and after an (admittedly cursory) glance at the language and documentation, my main intuition for why it hasn’t been adopted is that it could be more standard. For example why not use an established language instead of creating one from scratch? The syntax and features of the language look similar to Nim for instance. The benefits would be network effect as well as developer tooling support for newcomers.
I don't really understand the criticisms of Nix being non-standard or a hard to grasp language. The language is basically JSON with semicolons, scoping and lambda functions. It has a really minimal syntax and few built-in functions, it's untyped and comes with no complex concepts like typeclasses, exceptions, monads, etc.
Replacing it with a general-purpose language is almost guaranteed to increase the cognitive load required to write a simple package or configure NixOS.
This complain sounds a lot like "Why didn't you pick <my language>, which I already know?", to me. Nim, besides being newer than Nix (~2003), has support for metaprogramming, parellism features, OOP... which is all nice but it's far too much for a language intended for writing packages and configuration.
I agree that the documentation is a major problem when learning Nix/NixOS but the situation is improving. My recommendation is to start by reading the Nix pills[1], which are a great introduction to Nix but also develop into a detailed explanation of the inner machineries of Nix and Nixpkgs.
Agree Nix is actually very simple language and it being purely functional and lazily evaluated is what makes Nix packaging so powerful, these properties are actively utilized.
I think what the problem is is not the Nix language but its stdlib - nixpkgs. It is rapidly changing (as they figure out better ways of doing things) often breaks backward compatibility (for example not long ago they removed fetchGitPrivate and the built-in is not a drop in replacement), large parts of it aren't well documented, or even not at all (people often add great features, but forget to update manual and it still gets merged).
Initially this was the hardest part for me about Nix, and I guess it still is, but once I understood the structure of nixpkgs it no longer takes effort to find what I'm looking for (unfortunately many times I still have to look at the code, but now I can find it easily).
The thing is that this problem wouldn't been solved with different language like scheme or even Python. The language won't help much with learning the structure of nixpkgs and the conventions used. While Nix Pills cover some parts of it, there's so much more it could talk about.
BTW for those who are struggling with this. There is also very useful command to immediately find the derivation: nix edit <derivation> which should be emphasized more.
Guix has partly answered that question. Scheme (Guile) is used for nearly everything - package recipes, build instructions, service configuration, OS configuration, etc.
I guess the reason is that part of the benefits come from being a (largely) pure functional language. The property that an expression must always evaluate to the same value does wonders to reproducibility.
I agree that adoption would probably be larger if the language was not Nix or Scheme (Guix).
Hopefully one day Nix's approach will be popular enough that GCC or Clang will be changed so that the hacks aren't needed.