As long as both competing chain-tips are adhering to the same rules, the chain with the most aggregate difficulty ("heavier") will win, regardless of height. Nodes performing the initial sync would automatically end up on the heavier chain by comparing the aggregate difficulty of the chain-tips offered by their peers due to headers-first synchronization.
However, pruned Bitcoin Core nodes already in sync with the "lighter" chain would not be able to reorganize to the heavier if they no longer keep all blocks up to the common ancestor of the two chains. Instead, such a pruned node would have to resync from scratch.
If an attacker controlled hashrate equivalent to 100% of the SHA-256d hashpower they would today be able to rebuild a blockchain of the same aggregate difficulty as Bitcoin's in approximately 186 days.
The checkpoint system is deprecated (see e.g. this GitHub-discussion), instead new releases of Bitcoin Core since 0.14.0 by default use an assumed valid block. The performance of the initial synchronisation is hereby improved by the same mechanism as checkpointing used: Up to the height of the
assumevalid block the verifying of scripts/signatures is skipped, only block validity is checked, the UTXO Set is populated, and any data on transactions that concern the node's wallet is collected.
The advantage of
assumevalid over checkpoints is that it doesn't force the node onto a predefined chain. The user can pick another block or turn the feature off completely in the configuration of their node. Bitcoin Core by default uses a blockheight that predates the release by multiple weeks.
As such, the defense against such an attack could be to collectively agree to resync with
assumevalid set to any block after the attacker's chain has forked off.