A BSOD is a kernel panic. It means a part of the kernel, the very core of the operating system did something real bad. It maybe scribbled memory, it maybe executed code that it shouldn't have. Programmatically, you'd need to get code in kernel space, and then somehow trigger it on demand. A bit risky for a prod server.
Normal Windows machines have a lot of state in processes and in the kernel. Whatever cleanup you need to keep the state consistent, well you just short circuited it.
Specifically a BSOD is (usually) a kernel (or driver) bug, the kernel is in a bad state, so bad it feels it can't clean up and would rather reboot, losing whatever good state it has just because it doesn't know what's good and what's bad. Any buffers could not get flushed to disk(s). Then it will try to clean up on reboot, but it lost a lot of context on shutdown/panic so it will be a conservative cleanup, having to pick through both good and bad leftovers from the panic.
So, some of your advantage on shutdown is gone on startup, since now it needs to figure out where it got it's legs chopped out from under itself. It needs to run chkdsk and clean up any disk blocks that were in a partial write state. USB disks cache a lot. You can turn off caching which would make it less likely to lose data on crash, but then not caching takes away some speed. Which files are you willing to lose?
In short, this is a bad idea. Any production machine that has this happen may be in an unstable state even after cleanup. This is bad.
I'd say just to take the hit of shutdown and restart. You'll lose whatever time savings you think you get the first time you need to rebuild the server because it won't boot or your programs can't start.