When that option is disabled, NVDA ignores all keystrokes with the injected flag set; i.e. all keystrokes simulated by applications rather than physically received from an input device. It does this because when NVDA intercepts a keystroke in order to get information before the application executes it (e.g. the arrow keys or backspace key), NVDA needs to capture the keystroke, do its thing and then re-inject the keystroke. If NVDA didn't ignore injected keystrokes, it would end up in an endless loop, capturing its own injected keystrokes, handling them, re-injecting them, etc.
When that option is enabled, NVDA uses some tricky logic to try to ignore only its own injected keystrokes, but allow others through. This logic involves things like nearby timing, keeping track of keystrokes NVDA itself sent, etc. Unfortunately, it seems this logic isn't perfect and can still interfere with injection by some applications, hence the option.
@NVAccess

@jscholes I do wonder if there's more going on, because I almost feel like it's a bit more responsive having that setting disabled.

I guess it's possible. If that setting is enabled, when NVDA injects a key (arrow key, backspace, etc.), NVDA has to wait to receive the key it just injected before it can proceed further. We use a kernel event to signal that and it should normally happen very quickly, but if something else has a keyboard hook installed or something like that, that could slow things down.
In contrast, if that setting is disabled, NVDA doesn't wait for anything because it just unconditionally ignores all injected keys.
@jscholes