From my own experience tutoring young CS students, user input is actually a tricky concept. If it were not for user input, the results of any program could be pre-compiled into nothing but its output.
You get one lesson from getting all the input right at the beginning, with argc/argv, but from that point on, its just the computer churning. You get a different lesson from getting input during the execution of the program.
I have found that the idea of getting input from the user is surprisingly non-intuitive, given that nearly every program we interact with on a daily basis does it. This suggests that introducing it early helps prune misconceptions about how computers work before they become a real problem.
Obviously not every student is the same, but a particular pattern I found occurs more than I'd like is that they can understand what a program should do when it executes but not how that actually happens. They can look at
BOOL x = TRUE;
And they can intuit that the program should print "Hello", but they can't intuit how a computer can possibly do so. As best as I can tell they figure the compiler does the "magic," and figures out which printf to use (we'll ignore optimizers for a moment).
However, when the values come from input, you can no longer think about the computer as a magic device which reaches the final result immediately. You have to see that it is following steps. We know this, but it seems many students don't grasp this at first.
If you have inputs coming from argv, its easier to keep this illusion going. If you have input during the program, after the program has already done something, you have to realize what's going on quicker. In particular, it gets you closer to the point of realizing that the input the computer asks for may vary based on previous inputs (press 1 to calculate the area of a circle, press 2 to calculate the area of a rectangle. Depending on the next scanf/gets, the computer will ask for one additional number or two)