Your comment doesn't seem to address what I was saying. I just described a situation where you might use JSON5 in development (so you can put comments etc in your dummy data) and JSON in production (so you get native performance).
Here's how I've solved the use-case you talk about. I built my development files in my own format, and then transformed them to JSON for the wire. In my mind, the hassle this involves is a down-payment I gladly make in order to be able to work with sharp tools.
For your particular scenario, where your file format is similar to json already, it's not a lot of work to parse the file, and remove lines which - when stripped - begin with '#'. That's five minutes' work.
Json is a wire protocol. We had XML before that, but XML tries to compromise between being a wire serialisation format, and lots of other features (e.g. human-editable, file serialisation, schemas).
Crockford's decisions are a picture of minimalism. He wanted to find a way to get a standard wire format, without making any changes to javascript to get it. Json isn't perfect as a wire format, but it remains effective as a balance of those priorities.
The original post says, "JSON's usage has expanded beyond machine-to-machine communication." This is the source of the problem - the author wants to compromise JSON's mission to serve a non-core functions, things that are unrelated to being an available-everywhere wire protocol.
If we do json5, pretty soon someone else will be pointing out that we need to encode json schemas. When we point out that it's a compromise on the mission, they'll say, "that's OK - we've already made the decision to make JSON a general purpose format. Look at the way we added comments, which goes against the mission."
We'll get into hassles with libraries and versions. This is the road to XML. We already have XML, it's a horror to work with, and the reason for that is that it tries to be all things to all people instead of being a sharp tool.
Before XML we had SGML. When XML was young, I was involved with projects that chose it because it was simpler than SGML. XML is now far more complicated than SGML, in different ways of course. Now people overlook XML (it's too damn complicated!) and use json.
Fortunately Crockford seems to have foreseen the problems here, and made hard decisions early (no comments) in order to entrench against a repeat of the pattern.
