Anyone working on libraries that are used by large programs can use them, like in the sort and timer cases described toward the end of the paper. When you work on libraries used by other larger programs you inevitably break them accidentally. This technique pinpoints the exact context of the breakage.
I can't talk about the actual case that lead me to ever need to git bisect a kernel in the first place, but at the same time I also learned how to make a minimalist one-C-file initrd, because what I needed to catch was visible under a /sys or /dev mount, or something like that. I later realised it's possible to do the same thing with Go in slightly easier syntax, if you cajole it in to producing a statically compiled binary!
Not really, it's only suitable where your code is processing some other large input that you don't understand, and when your changes are usually easily toggleable at runtime and can be applied to only part of the input.
I assume you were talking about using hashes to encode some property of the program that you use for bisection. git bisect is still bisection but somewhat different IMO
I would frame it differently: stack hash bisect is only suitable where your code is linked into some other large program that you don't understand, and when your changes can be toggled on a per-invocation basis. Then you can use it to identify the exact stack through the larger program that leads to your code and works with the old behavior but breaks with the new behavior.
(saagarjha seems to be talking about 'git bisect', which is not really what the post is about.)