Not a theory per se, but my "lightbulb moment" with jq came when I thought about it like this:

jq is basically a templating language, like Jsonnet or Jinja2. What jq calls a "filter" can also be called a template for the output format.

Like any template, a jq filter will have the same structure as the desired output, but may also include dynamically calculated (interpolated) data, which can be a selection from the input data.

So, at a high level, write your filter to look like your output, with hardcoded data. Then, replace the "dynamic" parts of the output data with selectors over the input.

Don't worry about any of the other features (e.g. conditionals, variables) until you need them to write your "selectors."

YMMV, but that's what's worked for me

I don't know of any formal theory, but it feels a bit like functional programming because you don't often use variables (an advanced feature, as the manual says). I kind of got a feel for it by realizing that it wants to push a stream of objects through transformations, and that's about it. A few operators/functions can "split" the stream, or pull the stream back into place. Like, uh,

in.json {"a":1,"b":2}

jq -c '{a}' in.json

{"a":1}

The . is the current stream, so if I just do ". , .", it's kind of pushing two streams along:

jq -c '.,. | {a}' in.json

{"a":1}

{"a":1}

Then, of course, say:

jq -c '{a, b, c: .}' in.json

{"a":1,"b":2,"c":{"a":1,"b":2}}

It was going through the . stream, and I pulled the . stream right back in while doing so.

So it kind of helps to keep straight in my head when I've kind of got multiple streams going, vs multiple values.

Someone (almost anyone) can probably explain better with formal theory, but I just kind of got a feel for it and kind of describe it like this.