AFAICT, as of commit a0a422c,  we have 2 different logics to evict outbound peers : lagging-chain (`ConsiderEviction`) and (`CheckForStaleTipAndEvictPeers`). The former to sanitize out lazy/buggy peers who have never sent us a valid header and are always staying behind our tip, the latter triggered in case of stale tip due to block variance to seek a better chain by rotating our outbound peers if we already reach an outbound limit (`EvictExtraOutboundPeers`).

Block-relay-only peers were introduced by #15719. Contrary to outbound full-relay peers who provided us at least a useful header, they're not protected by lagging-chain eviction.

We actually have a comment inside `ProcessHeadersMessage` indicating the contrary behavior. We should either document cleanly that block-relay-only aren't protected or effectively extend the scope of protection to them.

Hinted during #19724 review, see https://github.com/bitcoin/bitcoin/pull/19724#discussion_r475144532
std::vector<CAddress> vAddrOk;
        int64_t nNow = GetAdjustedTime();
        int64_t nSince = nNow - 10 * 60;
        for (CAddress& addr : vAddr)
        {
            if (interruptMsgProc)
                return;
            
            
            
            if (!MayHaveUsefulAddressDB(addr.nServices) && !HasAllDesirableServiceFlags(addr.nServices))
                continue;
            if (addr.nTime <= 100000000 || addr.nTime > nNow + 10 * 60)
                addr.nTime = nNow - 5 * 24 * 60 * 60;
            pfrom.AddAddressKnown(addr);
            if (m_banman && (m_banman->IsDiscouraged(addr) || m_banman->IsBanned(addr))) {
                
                continue;
            }
            bool fReachable = IsReachable(addr);
            if (addr.nTime > nSince && !pfrom.fGetAddr && vAddr.size() <= 10 && addr.IsRoutable())
            {
                
                RelayAddress(addr, fReachable, m_connman);
            }
            
            if (fReachable)
                vAddrOk.push_back(addr);
        }