Doug McIlroy (the inventor of Unix pipes) included this in his description of "the Unix philosophy":

> Write programs to handle text streams, because that is a universal interface.

ESR expanded on this in the "Unix Philosophy" chapter of The Art of Unix Programming:

> Unix tradition strongly encourages writing programs that read and write simple, textual, stream-oriented, device-independent formats.

> Before devising a tricky binary format to pass data around, it's worth experimenting to see if you can make a simple textual format work and accept a little parsing overhead in return for being able to hack the data stream with general-purpose tools.

(And no, journalctl and systemd-cat don't fully replace the ability to run text-processing programs like grep, head, tail, etc. directly on the stored data.)

Well, I guess you are also against SQL databases, aren't you ;).

grep, head, tail, etc. work great when you have a small amount of logs. But if you have a production system with lots of logging data, processing plain text can become too slow and/or icky parsing-wise.

The tool being criticised outputs as a text stream. Which can then be used by every utility you have referenced. I'm still not following what the issue is here?

That's because cat is unixy. You can concatenate any file to any file with it. That doesn't mean those files are unixy, it means the program is unixy.

Not sure I understand your point. You just stated the purpose of cat, the tool being criticised isn't cat (so badly named) but does one job well - output binary logs into textual form onto standard output.