A peer is always placed into the denylist if:
An attempt to establish a new tunnel fails because of a time out (SCCRQ and SCCCN timeouts)
The timeout occurs on any control packet within an already established tunnel. All sessions on such tunnel are terminated (PADT is sent toward the clients, StopCCN is sent toward the LNS). Other tunnels that are terminated on the same peer times out on their own (if the peer is indeed non-operational), for example, the 7750 SR not explicitly tear them down based on the timeout of a single tunnel. The timeout of an existing tunnel is caused by the lack of acknowledgments to be transmitted control packets (ICRQ, ICCN, CDN, Hello).
A tunnel timeout occurs if an acknowledgment is not received after max-retries-established (on an established tunnel) or max-retries-not-established (for the tunnel in the process of being established) retries.
Although there is no configuration option that would control whether a peer can or cannot be denylisted (it is always denylisted on tunnel timeout), the amount of time that a peer remains in the denylist is configurable within the tunnel-selection-blacklist CLI node.