All of these functions are simply math functions. When you call them, they do math on the numbers you give them, and give you back a number. Nothing more mysterious than that.
Does it ever stop calculating the distance and slightly moving the camera towards the location
Lerp never calculates a distance and it never moves your camera.
Your code might do those things, and your code calls
Lerp somewhere in that process. Every time your code calls
Lerp, it does its work, which is very simple:
public static Vector3 Lerp(Vector3 a, Vector3 b, float t)
t = Mathf.Clamp01(t);
return new Vector3(
a.x + (b.x - a.x) * t,
a.y + (b.y - a.y) * t,
a.z + (b.z - a.z) * t
You can see there's no distance calculation or branching logic to decide whether it should do anything hiding in there. It's just six addition/subtractions and three multiplications. You'd have to run this millions of times in a frame to measure the cost, it's so cheap.
For one-off scripts like your camera controller, this simply is not something to worry about. You're going to be taking a cache miss when you fetch the camera control script and data from memory anyway, which is already hundreds of times more expensive than this little bit of math. (And your processor might be twiddling its thumbs waiting for the next object it needs to arrive in cache, so you might be able to do a significant amount of work here "for free" while you're waiting anyway)
SmoothDamp are a little more complicated (you can see their implementations too at the link above), and
Slerp involves some trigonometry, but they all fall into that "effectively free when you're using them in a one-off script" category.
New coders often think that the way you make a program fast is to make little micro-optimizations to every line, believing that any excess cost adds up / that any minor saving should add up to a significant speed-up, if you do enough of them. Unfortunately that's not how modern computers work. You'll typically be bottlenecked on a few rate-determining steps, like the time it takes to render the frame. Making other parts of your code faster doesn't make the game as a whole run any faster if it's still waiting on those bottlenecks.
So: always profile first. Measure what parts of your game are actually making it slow, then investigate ways to solve those.