Being able to use SPACE, PGUP, PGDOWN, END and HOME is important because it is default browser behavior for scrolling pages. In the current impl, that behavior is broken because of some complex nested overflow and scroll policy. The user needs to click into the scrollable area to ensure focus is correct so those keyboard events are handled. That's the first problem that ought to be fixed: if I'm on the results page, pressing HOME should scroll to the top of active log. The other keys should work too.
If we properly support those keys, then we need to think about how karaoke should or shouldn't continue to operate. My proposal was, simply, "if the user is moving around in the logs, don't automatically scroll the UI." The exception being that if they jump to the bottom of the logs, it probably makes sense to continue to show them what's currently happening.
It may sound "overcomplicated" but really it's just a proposal to align with end user intent. Giving them a button to toggle karaoke is just another step for the user - one that requires they use a mouse. Not all developers like mice: just ask the thousands (millions) of developers that use vim or emacs as they primary editor.