How those bytes are interpreted is up to the endpoints of the streams. Sure, a lot of endpoints interpret byte streams as text. That's not Unix, that's a particular endpoint.
You will notice that Unix does not even offer 'text' files (like Windows does). Or ISAM files, or random access files. or Fortran carriage control. Just binary files. Because the Unix way is streams of bytes, and nothing more.
Further if you wanted to go with JSON or something you can, there's nothing preventing it. Pipes are based on unstructured text so you have that flexibility. If you want to add JSON ls and filter that through JSON sed to JSON less you can.
Finally 'the Unix way' is a cultural thing. It isn't set in stone. It can, and probably has evolved. So while you could argue that it meant that to some people at some time, that doesn't make it true today or in the future. The down side is that we have these disagreements over what 'the Unix way' is. But any philosophy that's been around for 40 years, in tech no less, has to be flexible, that's why it's stay relevant.
I disagree, the unix way has structure: lines of text each consisting of space-separated fields. The real issue is that sometimes your data has spaces, or even newlines, so the structure quickly isn't enough. And that "sometimes" happens xay more often than it has to, and the escape hatch is a mess.
> lines of text each consisting of space-separated fields
I wish! Back in the day, tools like iostat and vmstat printed tabular data using fixed width fields with no spaces between. This worked fine until the computers got bigger and faster, then the larger numbers filled the fields so they ran together making the output unreadable. A surprising number of vendors had this problem.
It's bizarre that this is the case given that ascii contains characters for this very purpose. There's record separator, group separator... Now if your data contains those, that's bad. But that's much rarer than containing ordinary whitespace.
I don't think so, this idea of JSON is a more modern interpretation and I'd say is counter to the UNIX philosophy, not an extension to it (it just so happens to squeeze into existing primitives a little better than e.g. a binary serialisation protocol).
Anything that you'd want to colour, the data should already be there.
Further I'm not sure the Unix way inherently requires completely unstructured text