While XPath is expressive and compact, XSLT is rather verbose; jq is as expressive as XSLT, but with the compact verbosity of XPath.
Instead, your point was that jq seems to have many advantages over json-path in general, and therefore PG should offer jq instead or, or in addition to, json-path.
IMO jq is considerably closer to XSLT than XPath - which leads me to figure that since xml has both that JSON can benefit from jq and json-path. I'm not inclined to dig too deep here but I'd rather take jq in the form of "pl/jq" and have json-path (abstractly) as something that you can use like "pg_catalog.get_value(json, json-path)"
I am not against to this idea. The jq and similar environments can have sense in JSON NoSQL databases. Using it in relation database in searching functions is a overkill.
