In eBPF's case, at least the verifier puts a static cap on the total number of instructions that can be executed when invoking an eBPF hook – a reasonable cap, not "this will terminate some time after the heat death of the universe". This means you can be sure your eBPF hook will always run to completion in practice, as opposed to timing out or wedging the system indefinitely. That's a real benefit, but it requires stricter limitations than you see in "Turing-incomplete because we can" languages.
This limitation also allows the verifier to be simpler, while still allowing the program to be JITted to high-performance native code, that is guaranteed safe without unnecessary bounds checks. That simplicity is a second benefit, albeit one for kernel developers rather than eBPF-program developers. (You could say the performance benefits eBPF-program developers, but more complex JIT designs can achieve comparable performance without the limitations.) In contrast, "Turing-incomplete because we can" languages are typically high-level interpreted languages: they're not particularly fast to start with, and they wouldn't get any faster if the restrictions on recursion were lifted.
Despite the two aforementioned benefits, I believe that eBPF's guaranteed termination is somewhat overrated; I think it could benefit from a mode that allows arbitrary loops, even if that would require moving some compile-time checks to runtime.
