In a well designed application it shouldn't really matter if you use setframeratelimit, vsync, your own calls to sf::sleep or something different.
What you want is to limit the framerate to something reasonable (say 60fps) so you don't burn 100% CPU by pointlessly drawing the same frame over and over, but at the same time have the fps high enough that you don't noticably skip (too many) useful frames. Any of the above methods can achieve that.
The thing you must never depend on is the frame rate being regular, since that will never happer no matter what limiting method you pick. That is, your application must (assuming you set a limit of 60fps) gracefully handle that some frames may still only take 10 or 15ms rather than ~16 and some will take significantly longer like 20, 30 or even 100ms.
The usual way to deal with this is to measure the actual time between each frame and then step your simulation forward the number of steps needed to catch up with the actual time taken and then draw that end result. So some updates you may not step the simulation forward at all and some times you'll step it 1, 2 or 10 steps ahead. Your simulation timestep and your frame/draw rate should be decoupled and not depend on eachother.
