SSH over http/https

SSH over HTTPS does not make sense. That just encrypts twice.
Other than that, the "risk" depends on the used encryption for SSH, and the quaility of certs used. As always, better encryption comes with lowered performance and added overhead.

More than that, it probably won't work.  Both protocols do an encryption handshake before they will send any data.  I don't know that you can use SSH inside an SSL/TLS connection because of that.

I think it comes down to implementation, what the business requirements are, and what level of risks you are willing to take.  (But then, that is a cop-out answer... because it always comes down to those elements.)
The most secure server configuration would be one that is turned off, has no power or network connections, and is sunk in concrete.  For most applications, there are pesky business requirements that require that we start relaxing some of those security postures.  For an offline root CA, for example, we forgo the concrete.  (Might limit ourselves, to merely a concrete lined safe... still no power/ no network .  :-) )
In what I would consider a 'secure environment', I'd want to very much limit outside access at all.  If you have a legitimate business need that requires remote ssh access to a box, and have already accepted that it is a requirement, then you need to decide which security postures you will relax.

SSH over HTTP - Use common sense.  If you can not have folks login using root level accounts... don't let logins with root.  Make certain the passwords are secure.  Keep up with security patches(!!).  Make certain you have 'good certificates', etc.

SSH over HTTPS - In theory, it'd provide slightly more security at the cost of performance and overhead (as has been stated.)  If the HTTPS certificate is compromosed, for example (or vis versa), you still have another... but if, for example, folks are in the habit of ignore certificate warnings/errors... then additional certificates have bought you nothing.  If both SSH and HTTPS are using the same implementation of SSL... (for example OpenSSL) you won't have the benefit of protection against a zero day attack against the OpenSSL implementations.  

I'd lean towards SSH over HTTPS, if I _had_ to allow SSH access... but realize any benefit over HTTP wouldn't be much.

I should also have mentioned that HTTPS and SSH use different default ports as well as different encryption schemes.  That means you would have to craft a custom solution to use them together.  May not be impossible but is unlikely to be easy the first time around.

Firewall typically refuse remote connection esp administration like through SSH. They can do it via Secure channel such as VPN or IPSEC. but there are some which pass the firewall check through the alresdy open 443 to allow SSH connections via HTTPS. This is why they turned it on. Otherwise I see this channel as a SSL channel with SSH authentication still as per what SSH does using a pub and private keys on the authorised computer identity. In short, I do not see it as security improvement.

The only thing that comes to my mind is setting up a SSL VPN first. Only then your question makes sense.