If your corruption is fixable without data loss or restoring then that's fine. Using Grasshopper technique he will have some confidence that his last backup will be good with no corruption in it. There's not alot of point of restoring a corrupt database with a corrupt database backup, assuming you can get it to restore. When you uncover corruption it needs to be dealt with immediately but its not always possible to fix without data loss. Paul's blog and this article from Gail Shaw http://www.sqlservercentral.com/articles/Corruption/65804/ describe perfectly how deal with a corrupt db and how you fix corruption is entirely dependant on the results of Checkdb.

Let's look at it from the other way. You run a backup nightly then run checkdb, checkdb shows up corruption. You follow Gails artilce and it suggests that you restore from a good clean backup, which backup do you use? the one taken just before the checkdb? what if that backup has corruption in it, your restore has fixed nothing and you still have corruption. If then have to restore from the backup from the previous backup, assuming checkdb comlpeted cleanly after it, you can have some confidence that the corruption occured between the running of CHECKDB jobs and you will need to use the older backup. All the while, the time it takes (downtime) to fix is ever increasing.

In truth the answer depends on the circumstance, but there is definately some beneift in using Grasshoppers technique.