The best security can be provided if the link gets analyzed at the moment it is visited. At this time the most recent reputation information about link and domain are available. And ideally the actual content behind the URL from the perspective of the visitor should be included in the decision too. This can be achieved if all web traffic of the user is analyzed in a TLS intercepting web proxy, as often included in corporate firewalls. Since everything is passed through the proxy no explicit URL rewriting need to be done.
Passing all web traffic over an analyzing proxy can not be done in all situations though, especially not if the access device is not in full control of the company - like when using devices not in full control of the company (BYOD). And TLS interception might be seen as a problem too, sometimes for performance reasons and often for privacy.
The second best option is thus not to have the actual content of the page from the perspective of the user, but at least analyze the link at the time of access to get the latest reputation information and to also check the content of the page from the perspective of the analyzer. This might be the same as seen from the user, but some sites detect analyzers and provide them different (innocent) content than the actual victims. This second best option can be achieved with URL rewriting in the receiving mail server. It might also be achievable with a plugin in the mail client or the browser which checks the link against some API or rewrites the link only at the time of access. Such plugins are specific for the mail client or browser though, need to be explicitly installed (might be done automatically on company managed devices) and might not be available for all clients.
URL rewriting (and plugin and web proxies) also allow interaction with the user, i.e. if the decision is not fully clear the user might be warned about potential problems but might be offered to continue if they are sure that the link is trusted. This reduces the impact of false positives.
URL rewriting in the receiving mail server has its clear problems though: anything which relies on the mail being unchanged (i.e. PGP, S/MIME or DKIM signatures) will complain about a changed mail. And URL rewriting is not possible with encrypted mails, while a web proxy still protects in this case too.
The worst option (apart from no checks at all) is to check the link ONLY when the mail arrives at the mail server. At this time there are much less reputation information available about the link, so the chance of missing a problem is much higher. Also the decision at this time is final, i.e. either the mail is blocked (or the link removed) or passed through without changes. So false positives must be reduced as much as possible which leads to an even higher rate of false negatives, i.e. of not detecting attacks. Of course, filtering obviously bad mails at this early stage is a good idea, and this option can also be used together with URL rewriting or access via proxy.
In summary: None of the offered solutions is perfect, each has its own problems. URL rewriting is a good alternative if analysis of all traffic in an TLS intercepting web proxy or if the installation of a security plugin in the mail client is not an option. It has its problems though with any kind of signed mails.