Some times "one thing" happens to be a big thing that you have to do 100% or not at all, and doing it well requires a hell of a lot of complexity.
Does a XSLT processor do "one thing": processing XML? Does a DSSSL processor for doing "one thing": processing SGML? (Hint: It has a Scheme interpreter built into it!)
As I said, jq is impressive. It is a JSON processor that implements it's own functional language, complete with variables, function definitions, arithmetic, recursion. There is no question that it is useful and will be the absolutely right tool for a number of jobs.
Likewise with awk. I really, really like awk. It is such an elegant solution to a common problem (text parsing and productions). It is also a functional language.
XSLT is also a functional language. An XSLT processor is expected to implement a standard (as opposed to jq and awk) - but that's a minor difference.
It is when you are required to blend the disciplines that the limitations sneak up on you. In powershell it works the same regardless of whether I process data from JSON, from XML, from line-oriented text, from CSV, fixed columns or or from database queries. Sorting, grouping, comparing, mapping, presenting, converting - it is the same skill set.
That is not so say that something like PowerShell can or should replace tools like awk, XSLT or jq. It should not. Period.
But for tasks where one has to use several formats, the lack of a sufficiently strong inter-command protocol causes the tools to bloat and include functionality that has nothing to do with the core task. Consider, for example, why jq needs a "@csv" function (called a "format string") - and @html, @sh, @base64!
My claim is that those functions have nothing to do with JSON processing.
The equivalent in PowerShell is handled by ConvertTo-Csv, ConvertTo-Html, Out-String or the [Convert] class.
It really comes down to a n*m problem. jq is just one tool that implements csv or html formatting (m formats). There are n tools (jq, awk, xslt, ...). Should they all use the same rationale as jq and implement csv formatting? Or should they stay away from that and just concentrate on the core task.
In PowerShell the equivalent of jq - the ConvertFrom-Json cmdlet - just converts from JSON. Regardless of whether the objects were converted from JSON, line-oriented text, database queries, fixed columns, XML - the output formatting is handled by tools that are optimized for that.
If I'm dissing anything it is the limited inter-command protocol of traditional shells. In this day and age we process complicated structures that are not easily expressed in line-oriented plain text.
Some times "one thing" happens to be a big thing that you have to do 100% or not at all, and doing it well requires a hell of a lot of complexity.
Does a XSLT processor do "one thing": processing XML? Does a DSSSL processor for doing "one thing": processing SGML? (Hint: It has a Scheme interpreter built into it!)