A challenge being registered does not mean that the channel will inexorably finalize. Participants have the timeout period in order to be able to respond. Perhaps they come back online after a brief spell of inactivity, or perhaps the challenger was trying to (maliciously) finalize the channel with a supported but outdated (or 'stale') state.
checkpoint method allows anyone with a supported off-chain state to establish a new and higher
turnNumRecord on chain, and leave the resulting channel in the "Open" mode. It can be used to clear a challenge.
The respond method allows anyone with the appropriate, single off-chain state (usually the current mover) to clear an existing challenge stored against a
channelId. This might be significantly cheaper than calling checkpoint (it leverages the fact that the chain has already seen a support for the challenge state, so providing a single validTransition from the challenge state to the response state implies the existence of a support proof for the response state).
It is important to understand that a challenge may be "cleared" by another more recent challenge. The channel will be left in challenge mode (so it has not really been 'cleared' in that sense), but some on chain storage will be updated, such as the deadline for responding.
Extract info from Adjudicator Events
You may have noticed that to respond, the challenge state itself must be (re)submitted to the chain. To save gas, information is only stored on chain in a hashed format. Clients should, therefore, cache information emitted in Events emitted by the adjudicator, in order to be able to respond to challenges.