any command, like your example of cat, will by default send the output of it's command to that console's stdout stream. (and any errors to stderr too) these by deafult appear on your terminal screen but in reality could go off in many different directions. the > then intercepts that stdout and subverts it into a file, which you basically know already i guess. so whatever way it's used, cat still just uses stdout, and it's bash or whatever shell that command is running under that either provides the output as visible to the end user in a console or redirects to a file or another command via a pipe etc... cat has no idea at any level where it's output has gone. if however you have a command liek say, curl, to which you pass a "-o file.txt" argument then this WILL know about it and open the text file output itself and write to it instead of writing to stdout, which would be it's default action.
if a script is running without a terminal then bash (or whatever other interpreter) is still left with the stdout data, and if it get's to the end of the command sequence and is left with data in stdout then it's dropped, presumably to /dev/null but i'm not sure if it actually does require a destination, it may well just delte the data from memory, that does seem more likely actaully. As for stdin, i'm a little less sure, i would be tempted to say that there is no form of stdin at all, and opening that socket will cause anythign to stall. although somethign like bash is bound to wrap that eventuality for anythign running inside it.