No, a background process group (job) is NOT killed by default when the session leader (the shell) exits, or when its controlling terminal is torn down.
There are only some special cases when that happens:
(1) The background job is stopped, in which case it will be sent a SIGHUP/SIGCONT pair of signals by the kernel. If the SIGHUP signal is not caught or ignored by a process, the process will terminate.
The definition of a stopped job is: any job containing a stopped process. A process sleeping on a blocking system call like nanosleep(2) or read(2) is NOT considered stopped.
(2) A process tries to read or write to the terminal which no longer exists, and exits (of its own volition) because of the errors it gets when trying to do so.
(3) The job is actually a foreground job. The kernel sends a SIGHUP signal to the foreground process group when the session leader / controlling process (ie the shell) terminates. The controlling process is itself signaled with SIGHUP when its controlling terminal is torn down, which usually causes it to terminate.
Even commands started with & are actually part of the foreground process group when they're started from a shell with no job control (which in most shells --but not in csh-- is the default when running scripts and subshells).
(4) You're using a shell like bash or zsh, which goes out of its way to send a SIGHUP signal to all its jobs when it's itself signaled with SIGHUP (per point 3. above, the shell being the controlling process), or simply when it exits (the latter only the default in zsh, but not the default and subject to the shopt huponexit option in bash).
The csh shell (either the real csh or tcsh) does not have that behaviour from bash or zsh. In tcsh (but NOT in the real csh) you can start a command with the hup builtin in order to have it hup'ed when the shell exits:
tcsh% hup sleep 3600 & tcsh% exit $ pgrep sleep [nothing]
(5) Your init system goes out of its way to cleanup any terminated user sessions. In its default configuration, systemd will signal all the processes from a scope with a SIGTERM followed by a SIGKILL after a delay, so nohup will NOT help you with that anyway. Also, systemd's idea of a scope doesn't match a Unix process session, so running a command with setsid(1) will not let it escape it, either.
You can probably change systemd's behaviour by tweaking away from their defaults the KillUserProcesses=yes, KillMode=control-group, KillSignal=SIGTERM and SendSIGKILL=yes options.
