I don't known if you've solved the issue since the question was posted, but how do you expect to know which is the carrier that is closer to the building at a given time, if you don't know their shortest path? It does not make sense. You need to calculate some sort of path-finding between building and carriers. And just after that, select the closest carrier. There is no logical way of selecting the closest before knowing how much close they are.
I'd love to have some lecture about that, but I only was able to find (a lot) of pathfinding where the unit itself searches the path, not the target searches the unit with shortest path
You see, there is the confusion. The two things are the same: path-finding. The only difference is that, you are right, there might optimizations for the case when you have to run it for multiple agents (e.g. carriers) but the target is the same for all of them (e.g. the currently selected building). It is still the same path-finding, but just optimized.
I will get into that shortly, but first let me just comment as a disclaimer that you are assuming just too fast thatthe a game from the 1990s was not using path-finding for doing the job you want just because of older computers. It is actually quite likely that it did use it. You over-estimate the CPU cost of path-finding and under-estimate its use in the past. Even older games employed path-finding fora bunch of objects.
That said, here is one way of optimizing the path-finding for the situation when the target is the same for multiple agents:
1) it can be simply called the "early exit approach". Sure, if you are testing path-finding for 10 carriers in relation to a given building, one of the end points of the path will be always the same: the building's position. And you are right: there is something you could do with that particularity of your problem that will help you immensely.
The process is the following. Suppose you have to try 10 idle carriers. So, you run a path-finding algorithm for the 1st and then finds the shortest path from that 1st to the building and save it's length (in terms of number of tiles, not in direct straight distance). Now, you start doing the path-finding for the 2nd. Whenever a path being evaluated gets bigger than the saved one, you stop and exit its evaluation. If it ends up being shorter than the saved one, then you of course substitute the former saved one by this new. You then move on to the next carrier. So forth and so on.
Depending on how you implement that and your map is, then yes, it can give you a great performance advantage, because you can stop evaluating carrier's paths faster.
Now, keep in mind that in all and any well-implemented path-finding, you have a couple of other optimizations that you should always consider.
2) search less: just by filtering out the non-idle carriers, you decrease significantly the number of objects to path-find.
3) search in fewer places: spatial partitioning is a god-sent. You can (and actually almost always should) divide your map into areas (squares, irregular areas, whatever). Then, the first thing is to detect which carriers are in the same area as the building (or in same area + neighbor areas). And these are the carriers you wanna path-find, not all in the map. This technically is the very basic optimization for any path-finding. Although people frequently forgot about it, it has been around in the game industry for quite a long time actually.
As a bonus, keep in mind that nowadays open-map games usually use nav-mesh for path-finding, instead of tile-based grids:
4) nav-mesh - no matter if your building game uses square tiles, hexagonal tiles or whatever, if your game can have nav-meshes built on the fly, your path-finding for a building game like yours will probably be very, very cheap, in comparison to any tile-based solution (squared or hexagonal).