This is because in order to determine if the target account is an EOA (externally-owned account) or an SCA (smart-contract account), you need to take an extra step, which costs extra gas AND increases your own contract's byte-code size:
With transfer, the associated stipend (2300 gas) protects your system from reentrancy attacks in a native manner, i.e., without any additional code that you need to explicitly implement in your contracts.
Since reentrancy-protection mechanisms such as the one linked above have been well established and thoroughly verified by now, you may as well use call, but you should nevertheless make sure that your system is indeed fully protected from reentrancy attacks (for example, by having your code audited by an external party).
If you don't trust yourself to properly add reentrancy-protection everywhere needed in your code, then you should use transfer, but note that you'd essentially be replacing the potential reentrancy vulnerability in your system with a potential frequent reverting of transactions in your system (either in the present, or in the future - when the gas cost of various opcodes is increased following an EVM upgrade).
In my case I only have to change the habit of using the transfer function in transactions between clients, not contract accounts, since I apply the reentry measures with the well known countermeasures.
We will then have to forget about the transfer function because of the possible future or present gas cost.
Problem that I have already experienced in some contract.
We will change our programming routines and adapt to this suggestion as good practice.
In general, send dropped, and now the transfer function as well.