Its important to note, especially with Linux that experimental can also mean "Code that someone dumped here, which at the time looked acceptable but may not be actively maintained".
I am a big fan of keeping file systems in user space, but I should also indicate that I am a big microkernel enthusiast. I find it practical and preferable to keep file systems in userspace for the following reasons:
Userspace File Systems Are Easier To Maintain
Take a moment to look at the ext3cow file system, a PHD project that gained a considerable amount of traction in a very short time. Its author graduated and then moved on to a career, with very little time to work on the file system. Because its out of tree, Linux's ever shifting internals between versions require anyone wanting to use it on a modern kernel to have in depth knowledge that not many possess.
If it used the FUSE API, it would be much easier to maintain, and the actual work that went into transforming ext3 into a copy on write file system would get more exposure. This also relates to in-kernel code that is gathering mold because nobody is brave enough (or bored enough) to touch it.
Userspace File Systems Are Easier To Debug
In userspace, you have awesome tools like Valgrind (and its friends like massif) which are invaluable tools and easy to use. The learning curve associated with kernel debugging is often too great for many people to just jump in and code. Note, I am making a clear separation of FUSE and micro kernel architecture, as noted in this answer. Some micro kernel based systems are extremely hard to debug, mostly due to races in communication between running services (vfs, block device, file system, ipc). In both instances, the code is easier to debug because its out of the kernel, provided having it out of the kernel does not introduce strange complexities.
In any event, I'll take GDB and Valgrind over noisy printk() debugging any day, or trying to make sense out of the rather cryptic kernel debugging hooks that are present in Linux. I'll also enjoy the ability to use whatever debugging (or even garbage collecting) malloc() implementation that I choose. The same goes with my C library of choice, provided that it works with FUSE. I'm not downing Linux's kernel library, but I like my creature comforts.
Userspace File Systems Are Easier To Use
Its a great benefit for underprivileged users to be able to mount and maintain whatever file system they want to use, but that is actually the end-game. If your file system is out of the kernel, it can advance independently of the kernel, which means users can upgrade tuned to your release cycle. You could conceivably achieve 6 milestone releases in the time it takes for Linux to advance to the next release candidate. This also allows distributions and OEM vendors to get your FS out in the wild where it gets the testing that it needs faster than it would if it was a kernel module.
Norman Ramsey already described the reliability factor associated with file systems as a service in a micro kernel architecture. However, reliability means not needing a reincarnation service that tends to hide (or put off) bugs and other issues. I do agree on the point that its nice if a failed root mount does not throw a kernel abort, but this is possible with monolithic FUSE enabled kernels as well.
In summary, writing a file system is hard enough without having to deal with running in kernel space. I'd much rather use the FUSE API, or study the IPC / VFS service implementation in a micro kernel based OS than write it as a kernel module.