The common use of Lerp actually hides what the math is doing. LERP is a linear interpolation between two values, where a decimal number between 0 and 1 describes how far along the scale the value lies.
So, for example,
if you scale is 0-100, a value of .3 indicates that the value should be 30. Percentages! But of course, we can use other scales, so a scale of 654 - 1782 with a interpolation value of .3 is 992.4.
It works out to:
(high - low)* interpolation + low.
Now, the common use in Construct 2 is to achieve a smooth curve approach to a value, such as a camera target. That way the camera smooths into the value, rather than having an abrupt end. If we look at the math:
Say we had our 0-100 example, with the .3 interpolation value.
First loop:
0-100, .3 gives 30. So we set position of the camera to 30.
Next loop:
30-100, .3 gives 51. So we set position of the camera to 51
51-100, .3 gives 65.7. So we set position of the camera to 65.7.
Etc...
Now, what ends up happening is that eventually the camera is moving by very small steps per step of the logic. But we are feeding the result of the previous step back in as into the logic to get the next step. Eventually, the camera starts moving by less than an integer per frame, which means that if you floor that value, it stops moving entirely, because every time the floor is causing it to reset the value to what it was. (going from 941, to 941.87, which gets floored back to 941, in your case, for example)
Now, it is a good idea to have an end condition for the move, to prevent small minute "drifts" of the camera. This can be achieved by having a condition to check if the distance between the camera and the target is less than some critical distance. If it is, snap it to the end value. Too much and you'll see the snap, too little and you'll get minute pixel shifts of some of your sprites, particularly if they have non-integer positions.
Hope that helps!