Yes, it is strange, because it doesn't give you the benefits of version control--which are essentially irrefutable.
Version control (usually) stores deltas of files. Changes are recorded, not entirely new files, along with a commit message--a message saying what these changes are. This lets you do a lot of things: you can trace the change of a file, you can effortlessly see the changes that might have introduced a new bug (i.e. if there's a bug in SomeObject, you can do a diff on SomeObject.cpp from revision to revision and see what's changed). It allows for much more coordinated collaboration between developers on the same project--two developers can work even on the same file, and so long as their changes don't directly override each others', any good version control system will merge your commits. If they do overlap, you'll be in a state of conflict, and you can resolve the conflicts manually and commit the fixed version in.
EDIT: For the sake of example: me and my devs have been working on Sharplike for about three weeks. We have around 270 commits from three developers. We regularly break things, and we regularly revert out to known-working versions and just keep on trucking. This vastly improves our productivity and lets us concentrate on working, instead of trying to remember what we did when we screwed something.
Basically: there's no good reason not to use version control.