Frankly, I'm not convinced this is a security issue, for example, when CSV output is generated with @csv, multi-line output works correctly, because CSV handles multi-line strings correctly. Similar observations can be made about @html, etc.

Raw strings only have as much structure as is ensured in their construction, and there's nothing jq-specific here. If one wants structured output that won't confuse some downstream parser, one has to ensure the right encoding is used, which may or may be JSON.

Thus, if one wants to use jq as an awk or sed replacement working with line-oriented data, one can do that:

$ printf -- 'Do it with %s!\n' "sed" |
      jq -Rr 'sub("\\bsed\\b"; "jq"; "g")'
Do it with jq

$ cat /etc/passwd |  # Averaging uids from /etc/passwd is of course nonsense!
     jq -Rrn 'reduce (inputs | [limit(3;splits(":"))] | .[2] | tonumber) as $n ([0, 0]; [.[0]+$n, .[1] + 1])
              | "The average uid is: \(.[0]*1000/.[1] | rint | ./1000)"'
The average uid is: 1715.038

So what we have here is that when the output is not JSON it needs to be appropriately encoded for the syntax expected by the consumer. I don't think this really deserves any sort of security warning.

Even with JSON output, if the elements encoded as JSON are sloppily constructed, they may already mediate some sort of "injection" attack.