The cat version much more clearly represents the flow of data. We read left to right, it makes no sense to me to have data flow written right to left (and only for input files, while output files read left to right).
When building commands up from basics, it makes much more sense to start with cat. I will typically cat the file to see it's contents, then modify the command with a pipe to another program, and make keep adding processing steps to the end of the pipeline. Your < inputfile.txt notation completely breaks this model.
Just because you read something on a webpage that one time doesn't mean it is the one true way.
No, it makes much more sense to start with the command that is to process the file. Most commands take a command line argument to specify which file to process. This mirrors the redirection syntax perfectly:
You say:
grep haystack needle.txt
or:
grep haystack < needle.txt
whereas this is more convoluted:
cat needle.txt | grep haystack
As a bonus the syntax looks the same for output redirection:
sort < infile.txt > outfile.txt
whereas this is not as readable:
cat infile.txt | sort > outfile.txt
What "makes sense" to you doesn't always to other people. In this case it's trivial, but it's a nightmare to debug larger scripts when there are lots of unnecessary redirections and if statements.
Shell scripts may be one-offs, but they tend to linger. It's not unwise to spend a few extra moments to make them readable and follow best practice. It is code after all.
Server:
Client: We tend to forget how the network is built, and how easy it is to use it with the right tools.