I've heard that FUSE-based filesystems are notoriously slow because they are implemented in a userspace program. What is it about userspace that is slower than the kernel?
Code executes at the same speed whether it's in the kernel or in user land, but there are things that the kernel code can do directly while user land code has to jump through hoops. In particular, kernel code can map application memory directly, so it can directly copy the file contents between the application memory and the internal buffers from or to which the hardware copies. User code has to either make an extra copy via a pipe or socket, or make a more complex memory sharing operation.
Furthermore each file operation has to go through the kernel — the only way for a process to interact with anything is via a system call. If the file operation is performed entirely inside the kernel, there's only one user/kernel transition and one kernel/user transition to perform, which is pretty fast. If the file operation is performed by another process, there has to be a context switch between processes, which requires a far more expensive operation in the MMU.
The speed performance is still negligible against most hardware access times, but it can be observed when the hardware isn't the bottleneck, especially as many hardware operations can be performed asynchronously while the main processor is doing something else, whereas context switches and data copies between processes keep the CPU busy.
Your application wants to read a file
Application asks kernel, kernel access filesystem (in kernel space ) checks permissions, handles file descriptor to application.
With user space filesystems you have a lot more relatively slow kernel-to-userspace switches:
Application asks kernel to open file, kernel calls userspace filesystem, userspace fs calls kernel for disk access, userspace fs sends data to kernel, kernel hands data over to userspace application.
With userspace filesystems, you have a lot more context switches.