Many terminal emulators show a scroll bar and allow you to see the "history" of what I think you call the "command running area". Your shell and many commands you can run from a shell just print to the terminal in a "linear" fashion, line by line. Your terminal emulator may be set up to remember lines that went off-screen, then it lets you scroll to see them.
Scrolling in less or man (which uses a pager that may be less, more or most anyway) is different. A program like less requests an alternate screen. The terminal emulator does not save anything. Scrolling (if any) happens because the program does it by controlling the whole screen.
Note there's a big conceptual difference:
The former method of scrolling involves your terminal emulator only, but neither the shell nor any program run by the shell is aware what part of the history you're seeing at the moment.
The latter method involves less or a similar program that in general may scroll by rewriting the whole screen again and again. The terminal emulator happily shows these changes, but it's the program that controls what you see.
The terminal emulator may (and does) display a GUI scroll bar. AFAIK there is no standard interface for a program like less to request such bar. What a program can do is to display its own bar using characters. Less does not do this, some programs may (example).
The program may or may not react to mouse scroll events. What you described ("I have discovered that …") is a pager reacting to PgUp, PgDown, Home and End1. Scroll events and these keys are transmitted as escape sequences in the same stream that carries what you type.
It seems nowadays you can make less react to mouse scroll.
If a program does not natively react to mouse scroll, a practical method is to translate scroll events to (series of) arrow keys or so. Your terminal emulator may be able to do it. It may be able to do it selectively, depending on the (local) command that runs in the foreground (e.g. it will do the translation only if the command is less, more or man).
It's possible to do the translation between a terminal emulator and a program. tmux can do it. See this answer and this one. The latter contains code for ~/.tmux.conf, the code captures WheelUpPane and sends 3xUp etc. In fact I use this or similar code. There are more reasons to use tmux, its primary job is multiplexing terminals (creating windows and panes). Selective translation by tmux may be better than selective translation by a terminal emulator if you use ssh2.
Whatever works for you, do not expect scrolling controlled by less or a similar program to be totally smooth. Even if the input is smooth (compare this answer) and even if your terminal was able to pass smooth data to the program (and I think it's not able), the program works with a grid of WIDTHxHEIGHT characters and there is no way for it to scroll by a fraction of a line. Technically a GUI terminal emulator should be able to scroll pixel-line by pixel-line, at least when it alone is responsible for scrolling (i.e. within what we called the former method); still the terminal emulators I work with always scroll character-line by character-line even then.
I guess translating one "tick" of mouse wheel to several up or down keys (and tolerating choppy updates of the entire screen) is the best you can do. If another answer proves me wrong, all the better.
1 Almost always fn is handled internally by the keyboard and the OS is unaware, it just gets different keystrokes. Apparently with fn your arrow keys become PgUp, PgDown, Home and End.
2 To clarify: if you run local less in the foreground, your local terminal emulator is able to tell it's less; but if you run ssh locally and then you run less on the server then your local terminal emulator can only spot ssh, it doesn't know what program runs on the server, its behavior cannot depend on the remote program. But if you run tmux on the server and you run less within tmux then tmux will be able to spot less because they both run in the same OS.