If you view a manual page directly in terminology, the following happens:
less (the manual pager) switches the terminal to the so-called alternate screen, the one that does not have a scrollback buffer and from which when you quit your application you'll get back to the previous contents of the terminal. This mode is typically used by fullscreen applications (viewers, editors, file managers etc.).
less is not able to handle mouse at all, and
terminology is perfectly aware that the application running inside is not interested in mouse events.
terminology (in fact most of the terminal emulators) realizes that these two conditions are met (i.e. alternate screen, no interest in mouse), it converts scroll events into up and down keystrokes. So
less doesn't see any mouse event, it only sees keypresses.
Now let's put
tmux in between.
tmux is on one side just an application running in your terminal. Depending on its configuration it may or may not ask for mouse events; I assume you have it enabled since that's the default. It is not necessary for applications running inside to have any mouse support at all.
tmux also switches to alternate screen.
tmux, on the other end, is itself a terminal emulator, just like
terminology. It keeps track (for each window/pane) whether the application running there is interested in mouse, and whether the application has switched to alternate screen. These states are not reflected towards
tmux's private business.
Theoretically there's nothing stopping tmux from behaving like graphical emulators do, and turn these mouse scroll events that it gets from
terminology into up/down keystrokes for
less running inside, since
tmux is perfectly aware that the application running inside is using the alternate screen and is not interested in mouse events.
This is probably a feature that's missing from
tmux, and I recommend you to file a feature request against them.
Let's make it more complicated if you're interested in juicy details. Let's take out
tmux for now.
There's a small problem here to note. With traditional mouse the scroll wheel usually generates more than 1 keypress, maybe around 3-5, because otherwise scrolling would be way too slow. Touchpads are able to report much smoother coordinates, some terminal emulators (including
terminology) do recognize these and hence report up/down keypresses one by one (let's say a single keypress after each 1/3rd unit of scrolling, unit meaning what the mouse wheel would do at once). (I don't have a mouse right now so I cannot verify that
terminology with a mouse indeed jumps by multiple lines, but I assume so.)
Reporting multiple keypresses at once doesn't make sense in some circumstances, e.g. at the search prompt of
less it goes back by maybe 3 entries of the history at once, it's totally useless and is a nice demonstration that this is indeed what's happening behind the scenes. With a terminal emulator like
terminology plus a touchpad this is not an issue if an application does not care about mouse, so you can scroll line by line in e.g.
less. However, if the application cares about mouse, you're back at the rough scrolling experience because the mouse protocol inside terminals can't report fine granularity, only the old-fashioned mouse scroll unit. E.g. in
mcview you can't scroll smoothly, only by multiple lines at a time.
tmux back in the game. It's an alternate-screen mouse-aware app, just like
mcview, so it can only receive mouse scroll events of old-fashioned large units. It should presumably send multiple up/down keystrokes at once, just as actual terminal emulators do on old-fashioned mouse scrolls, otherwise scrolling would be unbearably slow. So, even if
tmux developers go ahead and implement this feature, you'll lose the smoothness of scrolling.
I've opened the bug https://bugzilla.gnome.org/show_bug.cgi?id=755183 to work on improving this, but no actual work has been done so far.