Is this a normal practice?
Well, it's more common (in my limited network security experience) to force the installation of a man-in-the-middle root cert on all clients on that network and then run a tool that uses the MitM certificate authority to decrypt and inspect TLS traffic. This doesn't work perfectly for some programs (which may use certificate pinning or have their own certificate stores) and is TLS-specific (there's an equivalent you could do for SSH, though I've never seen it done).
(You didn't ask, but) Is it a good idea?
Honestly, if it's being done by port filtering, it's pretty trivial to bypass. There's no rule that says SSH must use port 22, or HTTPS (never mind any other TLS protocol) must use 443; those are merely the defaults. I could simply set up an external SSH server listening on another port, then SSH to it and use it as a proxy to bypass the monitoring. You can't even do this by simply whitelisting ports; so long as I don't have anything else (like a web server) running on port 80 on my machine, I could set up my SSH server to listen on that port.
It's much more effective to restrict connections - especially outbound ones - in general. Only allow them with the specific combinations of addresses, ports, and protocols that are required, and nothing more. If you have some specific reason that your machines need to make outbound connections to UDP port 9670 on the 18.104.22.168/25 subnet (all numbers sourced rectally), you can allow exactly those connections and no others.