Netcat can do this on an ad-hoc basis.
This assumes your client side is either a desktop environment with the ability to open multiple terminal emulators (or tabs), or a server on which you're using a multiplexer like tmux.
This is because it's easier than pausing the SSH session in a single terminal.
Other variants of this use a remote forward but I think this opposes the mental concept of the remote machine serving the file and the local machine requesting it.
Set up a local port forward on-the-fly in the open session with Enter ~ C (in sequence) to get theSSH command line, then:
-L127.0.0.88:7777:127.0.0.1:7777
and Enter again to commit it.
I Ctrl + L to tidy up the scrollback, here.
The .88 is because IPv4 loopback is a big range and you can keep the port numbers consistent but use a different address per remote server, and it helps differentiate which side is which.
You can use .1 or whatever.
The port numbers don't have to be the same at each end.
Still in the SSH session, serve the file:
nc -lN 127.0.0.1 7777 < path/to/remote/file.ext
(You can shorten the first part to nc -lN 7777 when the address is the same as localhost.)
On the client side, switch to another terminal tab/window, and request it:
nc 127.0.0.88 7777 < /dev/null > path/to/local/file.ext
The /dev/null makes your request empty, but it could be any message that you want to go the remote server command's stdout.
Because this uses io-redirection, you can also use pipes to send to and receive from whatever program at either end. E.g. to copy a remote file's contents to your local clipboard you change the client request to something like this:
nc 127.0.0.88 7777 < /dev/null | xclip -selection clipboard
You can make the forward permanent in ~/.ssh/config if you use it often enough:
host your-remote
LocalForward 127.0.0.88:7777 127.0.0.1:7777