The halting problem is like the pigeonhole principle. Just because there is no general compression algorithm doesn't mean we don't use compression all day every day. We have solutions for many interesting subsets of the problem domain, and that's good enough.
We can also tell if a program will halt in no more than N clock cycles by providing the analysis with a budget. If the budget is exhausted then the program would keep running for an unknown duration longer than the limit. Possibly 1 cycle. For third party code, you could just refuse to run that code at all. There are some useful programs that would get rejected but there are many useful ones that would not. So implementing an "infinite loop detector" as a "really big loop detector" wouldn't be the dumbest thing to try, anymore than implementing video compression is.
The difference is that with data compression, you don't get random-looking inputs and would explain why text, voice, image domains are amenable to compression algorithms. In contrast, the state space of programs is exponential in the budget N and looks very random. The exponential explosion makes the analysis very inefficient relative to hardware ability. And then the random-looking state sequences are especially not very compressible. These characteristics are harder to leverage.
The pigeonhole principle works for lossless compression but I don't see the analog to Halt or Rice's theorem, etc.