With controlling terminal, process is able to tell kernel which process group is foreground process group (in same session). If there is a foreground process group for a terminal, we can control the foreground process group via the terminal, e.g., Ctrl-C/Ctrl-\ to terminate the foreground process group. (A terminal may have only one foreground process group, or may not have any.)

With controlling terminal, even if you already redirect stdin to other places/files, you still be able to read/write from/to controlling terminal, the /dev/tty. This special file is a synonym within the kernel for the controlling terminal of current process. If your process has no controlling terminal associated, then open this file will fail. What can you do regarding this file? E.g., some programs need user to input password before doing something, such as programs for login or encryption. These programs may prohibit user from inputting password from stdin, which means even if you redirect their stdin to a random file, they'll still wait for your type. The reason is they all open /dev/tty to read.

To sum up, with controlling terminal, kernel is aware of where to deliver terminal-generated signal and terminal input if they are expected by someone. That's all.

So it is unnecessary for a process to associate with a controlling terminal, if it doesn't want to be controlled by any terminal, and doesn't want to read/write from/to "/dev/tty" (like most daemon programs). However, a common process launched from within a shell always have controlling terminal associated, because it is member of shell session, which has already established a controlling terminal when shell starts up. (Actually, a random process cannot attach a terminal as controlling terminal, only session leader process can.)

With controlling terminal, process is able to tell kernel which process group is foreground process group (in same session). If there is a foreground process group for a terminal, we can control the foreground process group via the terminal, e.g., Ctrl-C/Ctrl-\ to terminate the foreground process group. (A terminal may have only one foreground process group, or may not have any. To put it precisely, a terminal can only be associated with one process session.)

With controlling terminal, even if you already redirect stdin to other places/files, you still be able to read/write from/to controlling terminal, the /dev/tty. This special file is a synonym within the kernel for the controlling terminal of current process. If your process has no controlling terminal associated, then open this file will fail. What can you do regarding this file? E.g., some programs need user to input password before doing something, such as programs for login or encryption. These programs may prohibit user from inputting password from stdin, which means even if you redirect their stdin to a random file, they'll still wait for your type. The reason is they all open /dev/tty to read.

To sum up, with controlling terminal, kernel is aware of where to deliver terminal-generated signal and terminal input if they are expected by someone. That's all.

So it is unnecessary for a process to associate with a controlling terminal, if it doesn't want to be controlled by any terminal, and doesn't want to read/write from/to "/dev/tty" (like most daemon programs). However, a common process launched from within a shell always have controlling terminal associated, because it is member of shell session, which has already established a controlling terminal when shell starts up. (Actually, a random process cannot attach a terminal as controlling terminal, only session leader process can.)

Controlling terminal is a total different concept from stdin. Why you have such a question is probably because you consider the controlling terminal as a stdin only, but it is actually more than stdin.

First, Controlling terminal makes your processs a foreground process. You can try, if you remove the controlling terminal from your process, it will become a background process immediately. Then you will be able to interact with shell again. You otherwise need to wait to interact with shell until your process exits.

Second, thanks to controlling terminal, kernel is aware of which process (group) is foreground process (group), which is background process (group). Because kernel is aware of this information, it knows the terminal-generated signals should be delivered to which process (group). (e.g., Ctrl-C, Ctrl-, and the hang-up signal)

Third, even if you already redirect stdin to other places/files, you still be able to read/write from/to controlling terminal, the /dev/tty. This special file is a synonym within the kernel for the controlling terminal of current process. If your process has no controlling terminal associated, then open this file will fail. What can you do regarding this file? E.g., some programs need user to input password before doing something, such as programs for login or encryption. These programs may prohibit user from inputting password from stdin, which means even if you redirect their stdin to a random file, they'll still wait for your type. The reason is they all open /dev/tty to read.

Please refer to APUE 3rd Edition, Chapter 9.6 for more details.

With controlling terminal, process is able to tell kernel which process group is foreground process group (in same session). If there is a foreground process group for a terminal, we can control the foreground process group via the terminal, e.g., Ctrl-C/Ctrl-\ to terminate the foreground process group. (A terminal may have only one foreground process group, or may not have any.)

With controlling terminal, even if you already redirect stdin to other places/files, you still be able to read/write from/to controlling terminal, the /dev/tty. This special file is a synonym within the kernel for the controlling terminal of current process. If your process has no controlling terminal associated, then open this file will fail. What can you do regarding this file? E.g., some programs need user to input password before doing something, such as programs for login or encryption. These programs may prohibit user from inputting password from stdin, which means even if you redirect their stdin to a random file, they'll still wait for your type. The reason is they all open /dev/tty to read.

To sum up, with controlling terminal, kernel is aware of where to deliver terminal-generated signal and terminal input if they are expected by someone. That's all.

So it is unnecessary for a process to associate with a controlling terminal, if it doesn't want to be controlled by any terminal, and doesn't want to read/write from/to "/dev/tty" (like most daemon programs). However, a common process launched from within a shell always have controlling terminal associated, because it is member of shell session, which has already established a controlling terminal when shell starts up. (Actually, a random process cannot attach a terminal as controlling terminal, only session leader process can.)