I do remember there was an issue that caused graphics cards to draw sc2 menus at unlimited frames which could damage the card but not the monitor. Honestly unless youre seeing tearing in the screen youre fine.
The issue was people with GPU's that couldn't handle running at 100% load, not particularly with sc2. It ran @100% load when not necessary, but hardware is designed to be ran that way. Tearing always happens, at any framerate, unless you are vsynced or gsynced
Ideally you'd have the game fps = your monitor's fps. So you see every frame the computer renders. However it's also acceptable to have a multiple of it, for instance if you have 120 fps and a 60 hz monitor, you'll only see every other frame your game renders
Monitors refresh in rows of pixels, if you have perfectly evenly spaced 120fps (frametimes are never perfectly evenly spaced apart) then you'd see half of every frame, not every 2 frames.
For example, the monitor would refresh the top half of frame 1, then switch to frame 2 and show the bottom half of that. 60hz just means that it refreshes every row of pixels on the screen sequentially at a rate that takes 1/60'th of a second for 1080 rows (on 1080p) with the frame in front buffer
Personally I feel V Sync (capped FPS at 60) makes SC2 lag more. I see it drop down to around 45 for no reason sometimes and stay there (it must be some bug with the engine).
sc2 doesn't have evenly spaced frames, so to have every frame faster than 1/60'th of a second (needed for 60hz vsync) you often need to be up around 100fps, or even a bit higher. I don't know of any way to cap FPS in sc2 without negative side effects, partially because the engine has no options for it, and the engine is one of the worst out of any that i know of for frame pacing
To answer OP question: A good FPS limit can add very minimal input lag, imperceptible ideally. Very few of them achieve that though, and it's "better" to run unlimited - the only question is how much better, how the implementation of limiting is in the game engine, and how much you care. Limiting FPS in a way where you delay the frames after they are drawn, like using a third party tool or some bad limits is a big NO. Using an in-engine command that's implemented decently like fps_max in the source engine or the one in Wildstar can be good. They work with some other info and do things like sampling input information at better times, instead of instantly sampling input, drawing frame and then holding it in a buffer for ages before you see it (high input lag). Third party programs interacting with games can usually only hold already drawn frames, they don't have other ways of frame limiting AFAIK, which is why it's bad to use them