I'm only aware of drivers, which were not sandboxed due to the nature of drivers (at least in late 90ties there was pobably not much of abstraction on that level, kernel features, hardware features available?)

There was -- Minix was developed in the 90s and ran drivers in user space. But it was (perceived to be?) slow, so mainstream OSes did not do it.

AFAIK the cause of BSOD were, among others, the lack of sandboxing.

This is a different kind of sandbox. BPF functions by drastically limiting the shape of the control flow graph that will be accepted for a program; most working C functions will not be accepted in a BPF program. The simplest example (complexified by more recent BPF verifier work that relaxes this... somewhat) is that BPF programs can't have loops, at least in the sense that a normal program can.

You can crash a kernel with a BPF program. But it's overwhelmingly likely that the crash will arise from buggy pre-existing kernel code that just hadn't been seriously exercised before eBPF gave people new tools to push that code with. What's much, much less likely to happen is a segfault or NPE in your own BPF code.