I think a lot of people would disagree with that statement. If you are committing that frequently then there are probably instances where you are checking in half written code that does not even compile. If you are using DVCS chances are your commits are still only stored on your local machine and just as susceptible to loss. If you are using something centralized or pushing your changes you are potentially going to disrupt the rest of the team unless you are working on a private branch. In that case, it seems as if version control is being used as a backup system where a substantial number of revisions cannot even be built. I think that is poor use of version control. It becomes difficult (at least for me) to analyze past changes (maybe months after the fact) when some of the versions are half-baked ideas that I committed for safety before going out to lunch.
I think there are two requirements here: 1) redundancy of work in progress and 2) change control management. I want my work in progress to be relatively safe from failures, I want it to be automatic and I want to be able to choose which changes are worthy of their own revision number in version control. Personally, when committing work in progress I want my revisions to represent a logical stopping point and not necessarily dictated by how much time has elapsed since the last commit.
I think there are two requirements here: 1) redundancy of work in progress and 2) change control management. I want my work in progress to be relatively safe from failures, I want it to be automatic and I want to be able to choose which changes are worthy of their own revision number in version control. Personally, when committing work in progress I want my revisions to represent a logical stopping point and not necessarily dictated by how much time has elapsed since the last commit.