Being able to rapidly prototype kernelspace things is probably the main advantage. I'd think twice about actually running garbage-collected code in the kernel in production. And the slide that touts that it's easy for users to modify -- yes, well -- you could easily argue that it shouldn't be easy for users to modify what's in the kernel :)
Easier is always good. It's still far from easy though.
The license is liberal, it's remarkably easy to work with Lua, is can basically call any of your C functions. Great for debugging stuff, prototyping, certain kinds of monkey patches. Great for doing unit test like experiments too; you can have some Lua put the system in to a particular state and then do your experiment.
If you need something like this, it's probably best to either host a kernel in userspace (like UML), or else have a lightweight kernel interface that allows you to do your heavy lifting in userspace. I've never done any Plan9 driver development, but my understanding is that Plan9 has userspace equivalents of most of the internal driver API calls, so that a driver module can almost seamlessly be developed as a userspace driver and then (if it turns out to be performance critical) run as an in-kernel module in production.
Once you've got good userspace APIs for the kernel APIs you need to use, then all kinds of rapid prototyping possibilities open up.