I rarely want text as output format, I want structured data that I can explore in a structured fashion.

As oblio said, you can come up with a standard conversion of structured data to text. The other way round you need write a parser for every textual output format, and typically people come up with fragile ad-hoc parsers that don't deal with edge cases properly.

I don't believe that. Text for human consumption, in a well designed UI (and I mean even a CLI one!), should be different from text for machine consumption. Human consumption generally optimizes for characteristics almost diametrically opposed from machine consumption.

Of course, who am I kidding, in real life we have some sort of crappy text interface which is half-baked both for humans and for machines. But we've been using it for almost half a century and it's too widespread to redo, so there we are, plowing through it daily.

Let's imagine the OS thought so, too, and had programs require implementation of both UIs, one for machines which is hard to look through by humans, and one for humans which is automatically presented in GUI form, meaning its hard to control and it's hard to parse the information it's presenting in a bitmap window (IOW an unautomatable interface). Now, I see 2 reasons to prefer the scenario we have now with unix and text based communication:

1) We don't need to depend on each individual program's programmer to present every control and information consistently between the 2 interfaces.

2) Automation matches normal, manual use. Just put what you normally do on the command line in a file and you're done. There's no need to look through documentation on how to do what you so frequently do, only in a manner that you rarely do.