The example is not really interesting, because as you said there is already a simple structure. But programming with text becomes really tiresome after a while. For example:

    git blame -L ${LINE},+1 --porcelain ${FILE} | sed -n '/^author / {s/^author //; p}'

I would rather:

    (name (author (first (git blame file :line line))))

... where git blame returns a sequence of "blame" data for which I can retrieve the author easily (if you prefer pipes over function composition syntax, use threading macros). Then I don't have to worry about strange characters crashing my scripts randomly. Suppose I forgot to add the "^" symbol in my regexp (I can assume this, since you assume people forget parentheses), there could be situations where I would match too many lines.

> You're making the format more verbose and error-prone (someone might easily forget to match a paren), without imposting any additional structure over what is already implied by line breaks.

It's already error-prone (as anyone who's ever incorrectly edited /etc/passwd knows).

Ultimately, structured data (which is pretty much all data) should be edited with structure editors. Good text formats make it easy to write such structure editors.

> What would your example achieve? You're making the format more verbose and error-prone (someone might easily forget to match a paren), without imposting any additional structure over what is already implied by line breaks.

That particular example is fairly straightforward (at a simple level, passwd files aren't complex), but being able to express arbitrary nested structure would make various things a lot more straightforward. Line breaks and some sort of tab/colon/what have you work fine if everything has at most two levels of hierarchy, but it starts being painful after that.

Missing matched parens are a bit of a specious argument, since many of the random formats for files are fairly strict about what they parse, and the ones that matter (e.g. passwd, sudoers, crontab) are conventionally edited through tools that check the syntax before committing.

Parsing columns of text with awk or any other text tools is vexingly problematic. How do you even define "column"? What if columns contain whitespace? How do you differentiate that from the whitespace between columns?

That just illustrates the limitations of the pipe abstraction, as something only able to send sequentially-read unstructured data.

Also, jq, jshon and similar tools are a thing.