See Tannenbaum et al's paper on reliability/security mechanisms for a nice intro:

http://cs.furman.edu/~chealy/cs75/important%20papers/secure%...

The main benefit is reliability. Driver code is usually lower-quality than other code that runs in kernels. The hardware itself can act weird in a way that messed the drivers up. The infamous Blue Screen of Death on Windows was usually driver errors. Isolating them in their own address space prevents errors from taking the system down. One might also use safe coding, static analysis, model-checking, etc when developing drivers themselves. Microsoft eliminated most of their blue screens with SLAM toolkit for model-checking drivers. Of the two, isolation with restarts is the easiest given you can use it on unmodified or lightly-modified drivers in many cases.

Far as security, it really depends on the design of the system and hardware. The basic, isolation mechanisms like MMU's might restrict the rogue driver enough if the attack just lets them go for other memory addresses. If it uses DMA, then they might control the DMA to indirectly hit other memory or even go for peripheral firmware. If the DMA is restricted, then maybe not. It all depends as I said on what the hardware offers you plus how the system uses it.

All these possibilities are why high-assurance security pushed in the 1980's-1990's to have formal specifications of every component, hardware and software, that map every interaction of state or flow of information. That didn't happen for most mainstream stuff. Without precise models, there's probably more attacks to come involving drivers interacting with underlying hardware that's complex. It's why I recommend simple, RISC CPU's with verified drivers for high-security applications. Quite a few folks from the old guard even use 8-16-bit microcontrollers with no DMA specifically to reduce these risks.

Far as verifying drivers, here's a sample of approaches I've seen that weren't as heavy as something like seL4:

http://spinroot.com/spin/whatispin.html

https://www.cs.dartmouth.edu/~trdata/reports/TR2004-526.pdf

https://www.microsoft.com/en-us/research/blog/p-programming-...

http://etd.library.vanderbilt.edu/available/etd-11172015-221...

https://lirias.kuleuven.be/bitstream/123456789/591994/1/phd-...

Note: Including that last one specifically for the I/O verification part.