Sure, and as another answerer of that SO question points out[0]:

> We are used to read from left to right, so a command like

> `cat infile | process1 | process2 > outfile`

> is trivial to understand.

> `process1 < infile | process2 > outfile`

> has to jump over process1, and then read left to right. This can be healed by:

> `< infile process1 | process2 > outfile`

> looks somehow, as if there were an arrow pointing to the left, where nothing is.

Sure, you can have the inputfile precede the process, but then you have to precede _that_ with a glyph which appears to suggest "send this data to the preceding command". You know and I know that that's not what `<infile` really means, but I claim (and others are free to subjectively disagree) that, in the context of an exploratory gradually-incrementing bash query, the extra brain cycles to remember what `<infile` really means are not worth the extra compute cycles of the extra process of a "useless" cat.

To someone who's fully internalized the workings of the shell, then sure, using `<infile` is _technically_ more efficient, at the expense of being less readable to less-experienced engineers. The tradeoff between readability and performance is always a case-by-case decision.

[0] https://stackoverflow.com/a/49254166/1040915