There's a whole Wikipedia section for this:

https://en.wikipedia.org/wiki/Cat_(Unix)#Useless_use_of_cat

It all makes a lot more sense now. I'm glad I can add demoggification to my vocabulary.

I usually use cat, because I often build a pipeline by starting with

  head filename | ...

then just change "head" to "cat" when I get it working, or grep if I want to check parts of a file, etc.

Likewise here, it maintains the left-to-right direction and "one operation per | gap |"

Bad code is code smell.

In this particular case, people (like me) would wonder, "what's the point" and then go searching for the details of how `cat` and `wc` work, assuming that there's might be a reason the original developer wrote this code, as opposed to the simpler `wc -l` (i.e. Chesterton's Fence).

People usually use it because piped input is a known interface, you don't have to go digging through a man page or help page to figure out what flag is needed to accept input from a file. "Data flows from left-to-right" is also very intuitive, and you don't need to know the specifics of how your shell interprets a command line to figure out where to put the input redirection in the case of a more complicated shell command.

The point is I personally find it more ergonomic. Just like how I'll take a slightly longer route to avoid turning directly across traffic or avoid a particularly dangerous intersection.

Also, context is really important. Not that people on the internet ever stop to think about what the context is that the person is writing the code in. I don't write bash scripts that run mission critical workloads. I just ad-hoc type stuff into my shell to produce output I need for stuff at the time.

Well one reason is programs being smart (dumb) about output if they think that dev stdout is a dev console. Using an extra cat eliminates this.