Why? That's a near useless-metric on any device with more than 32kb of ram, and highly variant on things like compiler and library minor versions.

In a time when computation is largely constrained by memory bandwidth, the size optimisation can have quite practical benefits. There will definitely be variance on different systems but this is why you standardise on the system for a competition.

Also, I think it's not quite so impressive to see a 100-byte source file turn into a few hundred KB or few MB binary as it is to see what could be done in a 64K, 4K, or even 256 bytes binary.

Modern processors commonly have 8MB of L2 and 16MB or even more of L3 cache. Shaving 10kb off a binary is meaningless.

Modern hard drives have gigabytes of storage, so shaving 100 characters of a source code is pointless. I always thought code golf was for fun more than anything.

...shared among all the processes in the system. Having 8MB of cache to yourself may seem like a lot, but share it equally with 100 others and you're left with ~80KB.

Obviously I agree (check out my page of teensy executables sometime), but it's much more complicated to compete on that metric. The size of a compiled executable can vary widely depending on details of your compiler and/or platform, making for a very unportable challenge. In a monoculture world, that would be more practical, but that's not how things are nowadays.

However, I will say that trying to minimize the size of the source involves much of the same kind of resourcefulness and lateral thinking that minimizing executable size does. So despite the drawbacks, it really is just as fun.