The best answer is: It depends.
You don't have to limit neither one
Updates: If your updates are not bound to an upper limit, then game logic should be dependent on a delta time amount, to avoid running the game faster or slower depending on the machine where it is run. This is a very common approach used by many games, but it is not the only one.
Rendering: If rendering is not bound to an upper limit, the framebuffer might be presented in an incomplete or erroneous state, causing tearing artifacts. This is why many games employ Vertical Synchronization (v-sync)
You might limit both
Updates: Some games make use of fixed timesteps for some or all of its gameplay systems. This approach works just as you've described. The number of Updates Per Second is limited to an upper bound to ensure things don't move too fast on a top notch machine. This removes the need for delta timing. Some applications are better with fixed timesteps, some with delta timing. Choosing which approach will depend entirely on what exactly you are trying to achieve. The online book GameProgrammingPatterns has a chapter dedicated to game loops that touches on both architectures.
Rendering: Frames Per Second should be set to an upper limit to avoid the afore mentioned tearing problem, however, your application should not attempt to do that manually with some CPU lock. Instead, enable v-sync and let the underlaying hardware synchronize with the refresh rate of the monitor. By doing that, your game will be forward compatible with future monitors which might operate on a much higher frequency then the currently commonplace 60Hz. It is also worth noting that many gamers, in particular those into benchmarking, still prefer to run without v-sync to allow the highest possible frame rate. So it is sensible to allow enabling or disabling the feature during runtime.
What you shouldn't limit
If your game uses a polling-based approach to user input, e.g.: calls a
getInput() of sorts to update controller states during the update step, then this is better if not limited. Or if limited, then set to a very high upper bound. The more often you query user input and act on it, the more responsive and smooth the game will "feel". The so called 60Hz games that we hear about nowadays are not updating AI and all world states at that rate, some are not even rendering that fast, but they query controller input at least 60 times per second and update the player avatar accordingly. Granted that this is only really relevant to fast paced action games.