It is no different from using a code generator for anything. Json2elm is designed to _help you_ write decoders, not replace decoders. Once you know how to write them, json2elm is mostly useful for generating boilerplate.
> I suppose you start every new project with mkdir and a few touch commands?
This is not a valid analogy (and no analogy is ever valid).
> In js it might be error handling and state management. In Elm, its decoding json.
Yeah, and Go has trouble with generics.
It doesn't mean it's a feature that has to be vigorously defended. Especially if it's basically the very first thing anyone will have to do in any web application in a language that is meant for client-side web programming
> It doesn't mean it's a feature that has to be vigorously defended.
I'm not sure anyone is defending it. At least, I'm not. Basically Elm's compromise is safety, and less runtime complexity then Haskell. The trade off there is boilerplate. As with most things, there is no free lunch. I've stopped using Elm precisely because of these issues, but I understand why Evan made the choices he did.