You may be able to dodge the issue by not mentioning compression explicitly. It's nonsensical that a single die roll takes 2.58 bits, but it's perfectly believable that 100 die rolls could fit in 258 bits. Then with a little work, you can show that 258 is the smallest expected value of any encoding. That uses the concept of compression as an intuitive model, without having to formally define it or call it by name.
Now we have something whose unit is "bits" but whose value includes fractions of a bit. What can we do with this? After all, if we're only storing one roll, we still need 3 bits to store 6 possibilities. The trick is that we can use fewer bits if we are storing more rolls at once. There are 2 wasted possibilities in those 3 bits we used for the first roll, and if you're clever, you can use those to encode some information about the next roll. If we're clever enough, and storing enough, 2.58... is the lower bound on the number of bits required per roll that you'll converge to with an optimal compression scheme.
It takes 3 bits to code for six values, but that is clearly a loose bound, since 2^3 = 8. But by taking the base-2 logarithm, you can get the exact number of bits required. That's how I rationalize it. The 258-bits-in-100-die-rolls is a nice trick though.
This is why the logarithm is my favorite mathematical function -- it's not just an operation on a number, but it also describes various properties of the number itself. Depending on how you use the log, it can describe the number of digits the input has, or how much "information" can be contained in the input, and so forth.
[1] It helped that the book gave axioms for uncertainty and then derived the -sum(p*log(p)) formula.