The Erebus attack can, according to the authors, be accelerated by causing the victim node to reboot* at opportune moments. This is because the node will pick new outbound peers from a list that's been compromised by the attack.
What's the reason nodes don't frequently store their current outbound peers to disk and reconnect at restart?
* by causing it to crash, which nodes are hardened against as much as possible
First, let me clarify that the Erebus attack does not require rebooting the victim. It is only for speeding up the attack process. The attacker can patiently wait for the existing legitimate connections to expire and occupy them.
Coming back to your question, I guess you suggested to prioritize reconnecting the current outbound peers among all tried IPs. It actually doesn't help much because: 1) the victim may reconnect to shadow IPs controlled by the attacker and 2) again, the attacker can wait for legitimate connections to expire.
The bottom line here is that, because Bitcoin is permissionless, you may not be able to know which are good peers and bad peers to reconnect to. If a node strongly trusts some peers, it can simply whitelist them. But overall whitelisting is bad for decentralization.
They do attempt to reconnect to previous peers. Each node maintains a database in the peers.dat file of all the peers it has seen, along with whether they are reliable or not.
Once connected to some peers (whether by reconnecting to previously seen ones, or peers source from the dnsseeds), a node will also constantly exchange peer information with other peers, so that they can discover additional new/unseen nodes as they show up.
