Say you're on a fork, in this process your node will rank all nodes also on your fork high on it's list because those forked nodes agree with your chain, where all nodes on the real chain are ranked low because they disagree with your chain.
Actually not, that's why latency takes important role. The node that's first on my list is going to have many disagreements with other nodes causing latency increases. Therefore, it's internal list of priorities is going to change. As a results, it's expected that node will have much higher latency due to overheat caused by rejected blocks with other nodes (that does not count as successful operations), and it will directly cause increase latency towards my node, putting it onto the bottom of the list.
The banscore system was one of inspiration for this, to be clear this is not from scratch. I went through the code in order to understand how we can improve, not replace. As for the Ddos, yes that method could be used to destabilize good nodes, but that's exactly why we are putting a small influence even towards those in forks, on placed on really bad ISP connection. Meaning, they are not necessarily on fork. In this scenario, these are actually helping network to heal until ddos stops. (at least in theory).
The another inspiration about this come from thinking on how to improve steem witnesses model.
And the third one is from real life experience of BGP routing implementation where I was able to confirm that this could be a working model. (Not necessarily for GRC and Steem, but for BGP shows great results so far).