In the two situations you give, the former will always go whatever percent you enter in regardless of distance and in the second you'll always go the distance (speed * time) you enter in regardless of end goal distance.
Calculating a speed and multiplying by the normalized vector will give you a consistent speed of travel toward the destination at the cost of normalizing (which uses sqrt). This is a pretty straightforward way of doing what you want and has the advantage of making it easier to store current momentum for if the target position changes.
Using Lerp will allow you to travel a percent distance between the two points very easily, but it will not only be dependent on the end point, it will also vary behavior on framerate if you do so repeatedly while updating the source position and leaving the destination. This is not an issue if you only update the percent value over time like you mention in your comment while leaving the start and end points the same. That being said you can do an extremely cheap elastic band effect by giving Lerp a fixed percentage and moving the start point to the current.
Overall they are two different tools with different purposes that can be used to the same effect (as per your example). While Lerp is going to be the faster between the two, the actual effect probably won't be felt unless you're doing it a lot (for instance, if you were doing it for every particle in a very busy particle system). To see if the speed difference matters for your purposes: try it, measure, then see if it's enough actively concern you.
As to the last part of your question, take a look at Vector3.MoveTowards. I'm pretty sure it's doing basically what you describe in your first example behind the scenes, but it's set up in a fashion similar to Lerp with the third piece being a distance instead of a percentage.