The Linux kernel itself is a a monolithic kernel and it beat out Hurd which was a micro kernel. I would say Linux has a history of certain programs being monolithic being a good thing.
Also, the userspace of GNU/Linux isn't called Linux. Linux isn't an operating system.
The established Unix philosophy of everything being "one program that does one thing" would be hugely beneficial if applied to an OS kernel. Wouldn't it be great you could just run different drivers and file system in userspace rather than having to compile a big kernel?
Not to mention that it could be much easier to develop them if they could just run as processes and die if they failed, as opposed to inducing a kernel panic.
Except that it makes debugging almost impossible and the overhead of IPC is very large. I'd argue that most popular kernels today (k{Free,Open,Net}BSD, illumos, Linux) are monolithic because that model makes development much simpler than a microkernel (not for historical reasons). Hybrid kernels like NT are a compromise for efficiency against the benefits of having a microkernel.
The panic argument is a good point, until you realise that kernel drivers don't panic --they oops. And a kernel oops just kills the thread it was running in. Linux has kernel threads that can be killed, but they're all playing in the same address space. So you can think of that as having the advantages of a microkernel without the debugging issues.
* http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/mi...
Last I checked, IPC overhead was not a barrier to performance in modern microkernels. QNX and XNU (used by OS X) both use microkernel-type IPC and are fast. XNU is even able to survive with an old Mach kernel.
If a kernel driver ends up in a faulty state (accesses invalid memory, does the wrong interrupt thing) then surely the whole kernel will panic?
NT is frequently referred to as "hybrid", but it's a frequently misunderstood design. First, while it uses IPC internally, it's not really comparable to microkernels since there's no context switch; every participant in the IPC communication is in the kernel. This is done purely as a way to isolate internals behind a rigorous, message-oriented API. Secondly, almost all of NT's services run in the kernel. A fairly small number of services run in userland: There's the user-mode driver system (UMDF, available since Vista), and graphics drivers also have the option of running partly in usermode.
I would be fascinated if Hurd could get the same sort of developer momentum to be comparable to Linux. A completely new (as in 1.0 released) and usable FOSS Unix-alike would be quite welcome amongst Linux and the BSD's I think.
Linux was initially written and released by one guy.
Linux obviously gained a wider team while Hurd languished, but it's still interesting that GNU's kernel efforts started with far more initial human resources and were still quickly overshadowed by Linux.