The model you are implicitly choosing

Which failure and synchrony models does a protocol assume, and what does it need from its failure detector?

Three choices are made before any protocol is picked, usually without anyone noticing.

Failure model

Crash-stop (a dead node stays dead) is the easiest, and it is wrong about restarts. Crash-recovery (a node may return with its memory erased but its disk intact) is the model nearly every real system uses. It is visible in the code. Raft persists currentTerm and votedFor to stable storage before responding, for exactly one reason: a node that forgets its vote can vote twice in one term and elect two leaders. That single fsync is the entire crash-recovery model made concrete.

// Raft vote handling (simplified)
on RequestVote(term, candidate):
    if term > currentTerm:  currentTerm = term; votedFor = null
    if votedFor is null (or == candidate) and candidate's log is up to date:
        votedFor = candidate
        fsync(currentTerm, votedFor)      // must be durable BEFORE replying
        reply(granted = true)

Omission faults (messages lost in one direction) and Byzantine faults (arbitrary behaviour, including lying) lie further out.

Synchrony model

• Fully asynchronous gives you FLP (named after Fischer, Lynch and Paterson): no deterministic protocol can reach consensus if even one node may crash, because "slow" and "dead" cannot be told apart and the protocol must eventually guess. FLP is not an academic footnote. It is the reason your failure detector is a configuration parameter and not an algorithm.
• Fully synchronous (known bounds on delay and drift) makes everything easy and describes no real network.
• Everything practical is partially synchronous: bounds exist but are unknown, or hold only eventually. That "eventually" is where the timeout lives, and it is the only place asynchrony enters a well-built protocol.

What the protocol needs from the detector

Consensus becomes solvable with the weakest failure detector, called Ω (omega): eventually, all correct processes trust the same correct process. Read this carefully. It requires nothing about accuracy now, only eventual agreement on one live node. That is why every consensus implementation contains a timeout-driven leader oracle, and why the timeout's only job is to eventually stop being wrong.

Compression: the protocol is safe in an asynchronous model and live only in a partially synchronous one, and the timeout is the sole place where the second assumption enters.