In general, by default the only difference is that it would receive a SIGTTIN (or SIGTTOU) signal if it tried to read (or write) the tty while being in the background.
Other differences as to priorities or higher context switches depend on your shell (or
screen) if it willingly does anything of that sort, such as changing the process’s “nice” number or maybe binding it to one particular CPU and if that CPU happens to be interrupted a lot. Normally shells don't do anything of this sort unless requested.
Higher probability of getting TCP timeouts might be related to whether your process does get stopped by one of the above signals (due to attempted tty access), in which case it wouldn’t have any chance to receive and therefore reply to network traffic.
If you think of it, daemon processes are the most “background” processes possible, and they certainly aren’t second-class processes.
I can’t be exact about specifically
screen’s detach operation but its documentation says that detached processes continue running, and that
screen detaches itself from the process's tty, so the process goes on basically with no difference as to normal foreground or background operation. You would have difficulties at giving it commands, though, being your interactive terminal detached from the process's virtual terminal. This might not be good for your process if at some point it expects input from its terminal.