I think this is a good point. It's definitely hard to grep for certain parts of gron's output; especially where there's arrays involved because of the square brackets. I find that using fgrep/grep -F can help with that in situations where you don't need regular expressions though.
It's not an ideal output format for sure, but it does meet some criteria that I considered to be desirable.
Firstly: it's unambiguous. While your suggested format is easier to grep, it is also lossy as you mention. One of my goals with gron was to make the process reversible (i.e. with gron -u), which would not be possible with such a lossy format.
Secondly: it's valid JavaScript. Perhaps that's a minor thing, but it means that the statements are eval-able in either Node.js or in a browser. It's a fairly small thing, but it is something I've used on a few occasions. Using JavaScript syntax also means I didn't need to invent new rules for how things should be done, I could just follow a subset of existing rules.
FWIW, personally I'm usually using gron to help gain a better understanding of the structure of an object; often trying to find where a piece of known data exists, which means grepping for the value rather than the key/path - avoiding many of the problems you mention.
Thanks for your input :) I'd like to see your jq script to help me learn some more about jq!
I have 5 line (!) jq script that produces this:
This is what I call grep-able. It's also eval-able.> What if there's json object with commit and json_commit?
Then I'll use jq to filter it appropriately or change delimiter. The point is ease of use for grep and shell.