While I don't agree with Falacy, I would not say that he is completely off topic either. Space requirements are something that should be considered; they just don't happen to be as bad as he thought.

Many applications that almost everyone has running every day (even if they don't know it, such as with background services) log tons of data.

We've been having some issues with Windows Automatic Updates with some computers at work recently, and I've had to wade through the update logs from time to time. Those things are very massive and are a huge hassle to go through. In fact, a lot of the data space is used on entire lines of seperators that have no data value whatsoever. And every computer has its own such log. And that's just a single one of many logs that computers have on them.

While I would not want to log every action taken in a game, doing so is not infeasible. Especially if the game maker wants to take their game very seriously and expend money on it, I can easily imagine someone buying an extra hard drive just for game data (maps, saves, etc.) and for these logs for a game.

Regardless of all that though, you can never get burned by having too much data to wade through, only if you have too little. If you end up having a very massive amount of data to sift through and you don't want it all, at the very least you can parse information out of it, either by using your own, custom made program to sift through the data, or simply by going to the command line and redirecting only certain lines of one file to another.

Since this is only slightly off topic, but is still related, I'll mention this here too.

It's always a good thing to learn to be familiar with a command line console. If you want to take a huge error log with full runtime error output that is very huge, you can sift out all the runtime error body text and look at only the runtime error titles with a single command:
type error.log|findstr "runtime error:">abbreviatedError.log
Then just sift through abbreviatedError.log.

However, the abbreviated log (which would be similar to what you get after the crashes are partially suppressed), aren't necessarily going to have all the information you need much of the time. Even if you get the same runtime error from the same line of code and same cause in a game, there could still be other data attached to it that is different that the extended error data gives you that could help to solve the problem.

One last time: it's always better to have too much information than too little, and to let the people who don't need it all sift some out, than to force the people who need it all to suffer.