Using -C with scp will result is drastic speedups most of the time anyway, it's possible any slowdown due to a nicer cipher suite can be counteracted with that.
That's orthogonal and compression won't help much if you're copying things that are already well compressed like archives, videos, photos... And compression only helps if you're I/O bound.
If using a stronger cypher is enough to slow you down chances are that you're CPU bound anyway and adding compression on top is actually going to make your transfer slower.
Making it slower isn't just a theoretical problem but I routinely saw that working with fast network hardware (1G, later 10G) on hosts which were either loaded with user tasks (computational lab) and have still seen it in recent years using hosts which are running AIX/Solaris/etc. where it's apparently routine for vendors to ship OpenSSH without any compiler optimizations enabled.
Depends on where the bottleneck is. A lot of the time scp is hampered by latency, moving most files that are not already compressed around will usually get some level of speed up on latent connections. Compression is also asymmetric, a fast remote host and a slow one being bottlenecked by decryption might see a speedup.
In theory, compression before encryption should make encryption faster on a multicore system. However, I'm pretty sure all ssh clients are single-thread, so that wouldn't apply.
If using a stronger cypher is enough to slow you down chances are that you're CPU bound anyway and adding compression on top is actually going to make your transfer slower.