I do a bit of it, so hopefully I'm not just wasting time. :)
Apart from being fun, I think it does
- give you a chance to 'practice keeping your mind challenged' (though many of us perhaps already have enough of that with normal jobs as developers)
- force you to consider multiple data structures/algorithms on an otherwise trivial problem
- provide some discipline about testing and refactoring
To expand upon bullet #2, I think it's often the case that in real life most (not all) day-to-day work does not require you to think too hard about data representation. In code golf, the 'shortness' criterion provides an (arbitrary/weird) constraint that forces you to consider more data representations than you would otherwise consider for a trivial program. Sure, a 2-D array works, but what about a 1-D array, or implicitly encoding the data in a giant lookup string, or ... I think these code-golf experiences help keep you 'awake' to the moments when data-representation choices really matter in 'real life'.
As to bullet #3, my usual MO is: (1) solve the problem normally, (2) write some unit tests and save everything, (3) start refactoring (typically in the opposite direction of normal refactoring) to make the code shorter. Occasionally I mess up and the unit tests catch me. This just help instill a unit testing discipline along with willingness to make changes to code without changing behavior.
Those are my thoughts, anyway. Maybe I'm just making up justifications to have fun :)