Hello,
 
FPS target is a frame limiter. It is useful for games that do not have an ingame FPS limiter and wanting to keep V-Sync off.
 

NacSquared
Right, so I have a GSync monitor so I'm not worried about going over FPS for screen tearing, more just conserving energy and heat. So it's beneficial in this regard, correct?

It's still relevant for you as a GSync user, since if you produce more frames than your monitor can display per second, you get all the latency of VSync, or if you have your surplus framerate behavior set to vsync off, you get the tearing you payed so much to avoid.
To delve into your first question, the GPU actually has no role in the FrameLimit functionality, it is entirely the driver and CPU.  The driver determines how long the last frame(or frames)took to produce, and suspends prerender of a new frame for an inverse amount of time if the frametimes are lower than what your target called for. If the frames start taking too long, the sleep interval will be mitigated or removed until minimal frametimes return. This is why these framelimits, even in the driver, are denoted by ~VALUE. It is an estimate. During some sample windows, the framerate will be above your target, if demand sharply decreases, or the driver might over sleep and miss a frametarget it might otherwise have made in the opposite case.
    Going back to your gsync situtation, you want to under Frametarget your monitors refresh rate, so the monitor is increasingly likely to always be ready for a frame the instant it has been rendered out. It may be easy to think, 'if I'm getting 155FPS against my gsync monitor, and I just vsync it to 144, or I frame target it to 144, the end result will be 144, so who cares?' 
Not exactly. In the frame target case, the excess time is consumed at the beginning of the pipe, so you may be getting 144FPS out the end, but your mouse movements are ignored during the prerender suspension, and then when prerender does happen, your MOST RECENT input is captured, and you see it in 1/144th of a second, the best lag that framerate can offer. In the Vsync case, you capture mouse input, render your frame reflecting that input, and then oh wait, you have to wait for the monitor to finish scanning, then the results of your input are displayed. The time in the vsync case is consumed at the end of the pipe, and there's your input lag. 
blurbusters has some empirical numbers on this behavior, and a frame target of 138-141 minimizes input lag on gsync 144Hz displays; due to the estimation misses of the framerate limiter, a limit of 144 or 143 is insufficient.

TLDR: FramerateLimit is an estimate. GPU driver will try and have this number be a reality if you have the ability for a higher framerate than the target, but it cannot predict the future. Framerate Limit is invaluable for those who are sensitive to input lag, even GSync users, with high performance parts and/or 60Hz panels. FrameLimit will have no effect if you cannot reach the limit in the current demand context. No up clocking or downclocking are cause by the limiter directly, only load balancing using sleep as a counter measure to excess performance.

SM