Is there any reason NOT to use the approach you've defined? Absolutely.
Imagine you had bought a car - a car that when you hit 50MPH the engine starts to overheat. Would your reaction to this situation be to artificially limit the car to 49MPH, or to find out what the fault is with the engine?
Why should you limit your car to 49MPH? The manufacturer stated that it could drive as fast as 80MPH - you like to drive your car fast so you want to get it to this speed - if it wasn't for that damn overheating issue.
The car you bought was also really, really expensive. Each engine cylinder needs to be utilised to the max so you aren't wasting that money!
By artificially limiting SQL Servers access to the CPU, you are missing out on performance. You may have temporarily resolved the performance issues by ensuring the CPU is available for the OS to use, but you haven't answered the real question - WHY is SQL Server using 100% of the CPU?
My advice is as follows:
Find out what the real issue is, and fix it. Don't cover the issue up with what is effectively a kludge. The issue WILL reappear and smack you in the face down the line when the workload of the server naturally increases with growth.
As a temporary fix, resource governor can be used to lower the CPU used, UNTIL YOU FIND THE REAL PROBLEM.