Brief answer: Were I running a software development team, I'd be inclined to allow it, possibly even to a level beyond the 1 day per week for some staff, but not to generally offer it to all staff.
Long drawn out answer with some background:
When first employed as a developer, my company offered "training days" - one day per month which you could dedicate to learning anything you wanted. A number of the staff used this time to build tools, etc, many of which proved extremely valuable, became adopted, with further work on them scheduled into real development time.
Outside of these training days, you were expected to perform scheduled development work, support work, bonus targets, etc, were built around this scheduled work, it's timeliness, quality, etc.
Despite this, numerous "personal projects" were certainly worked upon by the development team outside of these training days (I had more than one over the years), and certainly, whilst not advertised, some time was built into the schedule to allow for this.
In my experience the "20% coders" (those responsible for the bulk of your teams valuable output) are the team members who "find the time" to work on these personal projects, which often (but certainly not always, at least one could be sportingly considered "team building") turning out useful tools for the team or the business.
Were we to have offered the Googlesque 1 day a week personal project option, I suspect it would have been embraced by the "20%" bunch more than the "80%" bunch, and for many it may have well have just been tagged "lazy time" and not delivered the value we'd hope.
All in all, when you're employing both programmer types (unlike Google, who obsess about these 20%ers) it seems sensible to allow it, but not to promote it.