Nix has supported JSON derivations for years, e.g. using commands like `nix derivation show` (I have Emacs configured to run that on any `/nix/store/foo.drv` file I open). It still serialises to ATerm on disk, to avoid breaking existing hashes; which I think is reasonable.
If you mean the programming language used to generate those derivations, then I have no idea what that would even look like; some horrific bastardisation like https://github.com/gliese1337/json-lisp ?
PS: I I found that json-lisp project with a quick search for a LISP-like language that used JSON instead of s-expressions. I like how its README says "Due to the excessive cumbersomeness of writing code in JSON, it is expected that most applications of this library will use it for interpreting auto-generated code of some sort, or API calls, or config files.". If we used that to generate Nix derivations, then we'd want a third* language to generate the json-lisp that generates the derivations ;)
What? No! Nix-the-language certainly isn't great, but there's nothing better about JSON/YAML in this role. The whole point of Nix is that it's a programming language that allows you to build abstractions in the language itself, not just pure data.
The fundamental basis of Nix is that it's a purely functional programming language without side effects. The whole thing breaks apart otherwise. And with a purpose-specific programming language, there's some big quality of life things (for example, low friction multiline strings with interpolation, the ability to use dashes in identifiers for package names, ...).
(and, when you can do without side effects, functional programming is really simple and productive!)
To be fair,the Nix code in a very simple config probably looks like some weird JSON like derivative to a layman because of how brackets heavy the language is.
I could see someone glancing over a tutorial and thinking "they should just use JSON instead of their own custom data format" without realizing that Nix is a functional programming language.