A few years ago I looked for any studies on the usefulness of a version control system over, say, a versioning filesystem. (Examples of such include the VAX filesystem which auto-versioned every save, Dropbox does the same for at least 30 days, and the Mac Time Machine gives access to previous backup snapshots.)
I wondered if for some projects auto-versioning on save or clock event in a VFS would be more useful than manual versioning with a VCS. For an common scenario, co-authors working on a paper might have a shared Dropbox directory. They can modify the images, Word document, etc. safely without risking forgetting something because there's the option to see older versions of the directory.
Those studies have not been done. I know for myself, for the initial stages of a project, I find it more effective to iterate through multiple directories (eg, "foo", "foo2", "foo3") so I can easily compare different approaches, than to create a new repo, name the branches, and check out each one to get the same effect. I also have hourly backups, so I won't loose much in the way of code.
It's very rare that a change will hit only one file, at the least it's likely to imply changes in the test suite as well, and likely there'll be several objects collaborating. Being able to group those changes together and then annotate them with a commit message is hugely useful to me for a couple of reasons. Firstly I can roll that change set back as a single unit, but more usefully I can look at the history of a given file, of even a given line of code, and then map the changes to the wider context that influenced them. I couldn't tell you how many times I've wondered just why a line is doing something, run git blame, and instantly been given an answer by a past version of me who still has all the details fresh in their head.
We don't really know, beyond personal experience, which is why this is very debatable.
It worked great, and even though I now use git for even personal projects, I'm not sure it's on balance useful, along the lines of your thinking.
Because: VC warps your thinking. You change your work habits and spend time crafting this artifact, the VC commit history, which is secondary to your actual goal. For example, there's a tendency to quickly jump between different areas, or make unrelated changes, because that works against the nice 'commit-per-thing' history that looks nice in VC.
So no VC doesn't seem so crazy to me :)
Even huge projects involving large numbers of people can be and have been done without version control, if you have a large enough project management staff. You'd be mad to try to do it that way merely because you can, now that version control has gotten so good, but it's still not a necessity. It's not vital.
In fact, I did just that yesterday.
And being able to visit old code? I can't remember a single instance in my career where that was important. I can imagine scenarios where it might be, but they've never happened in real life. The other thing I realised is that most source control systems are useless if you change a file's name, you can get to the old file, but you simply can't be bothered. So it's actually easy to effectively 'lose' old code through refactors.
Source control is great for looking up the 'why' of what you did 6 months later and for backups.
The stupid guy that wrote this ugly code was me too.
I still use a VCS, if only for synchronizing code between computers, and for actually erasing dead code without regrets.
Otherwise we would be judging all programming languages by the use cases and the pitfalls of COBOL.