> What's natural about cat on only one file?

It's about building the query, really. Here is example:

    cat file.log

"Oh, it's too big, I only care about these messages"

    cat file.log |grep error_name

"don't care about old stuff, show me the new one"

    cat file.log |grep error_name | tail

"hmm, show me when it started, and let's ignore monitoring checks"

    cat file.log |grep error_name | grep -v 'user: mon'| head

"okay, but maybe log was rotated ? Let's see last week"

    zcat file.log.1 |grep error_name | grep -v 'user: mon'| head

"hmm, it's some old error, let's search some more logs"

    zcat file.log.{10..1} |grep error_name | grep -v 'user: mon'| head

(zcat will auto add .gz if not passed)

You can't for example do

    < file.log.{1..10} zcat

> What's natural about cat on only one file?

What's natural about using tar to create .tar.gz files instead of using them to archive files to tape?

"cat is to catenate" sounds like an argument from people that need to get out and smell the flowers once in a while

From 'man cat'

> cat – concatenate and print files

So if I want to print a file to stdout, I'll use cat, thanks.

Of course it's reasonable to use cat on one file. Why should it work for all 𝑛≥2 files, but suddenly fail at 𝑛=1?

Despite the dismissive tone of the article you linked, if the overhead of one single process was remotely relevant, shell wouldn't be a good fit.

Catenating a file with the output stream is quite useful in many circumstances. Paged data isn't always wanted, and it's not generally known if filters are needed before the file is seen. Cat is the standard way to print to stdout.