What's the purpose of specifying multiple good commits when using `git bisect start`?

I was reading the official documentation for git bisect and found the following description:

If you know beforehand more than one good commit, you can narrow the bisect space down by specifying all of the good commits immediately after the bad commit when issuing the bisect start command:

$ git bisect start v2.6.20-rc6 v2.6.20-rc4 v2.6.20-rc1 --
                   # v2.6.20-rc6 is bad
                   # v2.6.20-rc4 and v2.6.20-rc1 are good

However, I can't fathom why do we want to specify multiple good commits.

If we have known there is a bug between rc6 and rc4 and tell git that rc6 is bad while rc4 and rc1 are good. Git will still bisect the commits between rc6 and rc4 regardless of knowing rc1 is good, won't it?

Questions

1. In what case do we want to specify multiple good commits to git bisect start?
2. If multiple good commits matters, how does git work when there are multiple good commits specified?

You're correct that you only need the latest single good commit if your history is linear. However, multiple good commits could be helpful when it's not linear. Consider:

X
|\
G K
| |
F J
|/
E

Suppose you know that X is bad and F is good. At that point any of G, J, or K could be the culprit. If you know both F and J are good, that narrows it down to either G or K.

As for your second question about how Git Bisect works when traversing multiple paths, here's an article which describes it in some detail.