Terminals with screens? What's all that newfangled shit?

Nah, whippersnapper, this tech goes all the way back to teletypes. You didn't get a fancy-shmancy "screen;" instead, it printed out the results of your commands. On actual paper!

Seriously though, that's why the device files for terminals in Linux are named tty[$NUM] -- "tty" is shorthand for "TeleTYpe."

I believe it's also why really primitive programs can't scroll up and do things like writing an entire screen worth of content in order to emulate interactivity (as opposed to seeking the cursor backwards and replacing only the parts the program wants to replace): they're using a version of the control protocol so primitive that it didn't have a function to go backwards because teletypes didn't need it due to physical impossibility. (That's my theory, anyway -- I haven't dug deep enough into the guts of TERMCAP etc. to be sure. I'm also not actually old enough to have experienced that stuff, despite my joke above.)

Edit: look at this excerpt from man terminfo(5), for instance:

Basic Capabilities
The number of columns on each line for the terminal is given by
the cols numeric capability.  If the terminal is a CRT, then the
number of lines on the screen is given by the lines capability.
If the terminal wraps around to the beginning of the next line
when it reaches the right margin, then it should have the am
capability.  If the terminal can clear its screen, leaving the
cursor in the home position, then this is given by the clear
string capability.  If the terminal overstrikes (rather than
clearing a position when a character is struck over) then it
should have the os capability.  If the terminal is a printing
terminal, with no soft copy unit, give it both hc and os.

To this day, the info database entry for your virtual terminal has to specify that it's capable of deleting a line of text instead of merely striking it out, because some terminals back in the day actually couldn't!