I'm not sure I agree completely with his characterization of what happens. I've noticed that people, particularly in larger organizatons, will start shoehorning their "hacking work" into real projects if it is left out for too long. So, you end up with systems that are on bleeding-edge languages, tools, runtimes, and platforms because, frankly, the team was just dirt-sick of Scala/Java + Beans, even though that would've met the company's goals much more quickly and cheaply.
That said, I definitely support his statement that people should have some hacking / learning time budgeted, even if only to avoid the scenario I mentioned above.
I completely agree. I've worked at a company where we had explicit weeks taken out of the schedule to do "app building" where we were expected to do a mix of kicking the tires on the product and experimenting with random tech we wanted to play with (subject to the Legal Overlords and their hatred for OSS, at the time). Speaking with my manager hat on, it worked quite well for exorcising those demons.
I've had good luck in the past doing these kinds of side projects as tools -- they're useful, but don't rise to the level of Mission Critical. This avoids the problems mentioned in the parent. (Organization becomes dependent on bleeding edge languages/libraries, etc.)
That said, I definitely support his statement that people should have some hacking / learning time budgeted, even if only to avoid the scenario I mentioned above.