From the definitions you listed, this one is applicable to modern Linux (and some other Unix) systems, not necessarily to mainframes:
Console means the keyboard and monitor physically attachements to a computer.
The other definitions you listed are more applicable to mainframes.
A connection between a mainframe and its console terminal might be a current loop serial port, a RS-232 (or its longer-range variant) serial port, or some proprietary solution. Having a PC-style GPU, keyboard and mouse be treated as a console is a more recent innovation that came after desktop systems became possible.
A mainframe might have had a dedicated communication processor or some other I/O card that was responsible for connections to terminals; but whatever the implementation, you would find in the mainframe box a number of ports labeled like "console", "terminal #1", "terminal #2" etc... and in order to meaningfully use the mainframe, you would have to plug in at least one terminal to the "console" port. The other terminals were optional, but without the console, you could not use the mainframe.
The "console" port was likely to have some privileges the other terminal connections wouldn't, like access to firmware settings and/or firmware-level debugger. When a Unix system was booted into single user mode for troubleshooting or major reconfiguration, the console would have been the only terminal that was usable in that state. In regular multi-user mode, the console might have had a slightly elevated process priority compared to other terminals, so in case a program was hogging all the CPU time to itself, the system administrator could still use the console to log in and stop it.
Because of this, the console connection was normally hardwired to a terminal in a physically secure location quite close to the mainframe: either in the server room, or maybe in the adjacent system administrator's office. Since it was a direct, hardwired connection, it would be usable even if any network or other input/output device drivers were failing.