UML was originally done as a kernel development tool. I wanted to do kernel work on my single machine and couldn't think of any reasonable way of doing that except by doing a userspace port of Linux. This has turned out to be its most popular use so far. A number of kernel developers and projects have started using UML as their primary development platform, and booting their work on physical machines later in the debugging process.
Any project which doesn't involve machine-dependent code or direct hardware access can do their development under UML and the code will run unchanged in a native kernel.
It is also possible to do driver development under UML. For some types of hardware, such as SCSI and USB devices, a userspace driver can claim a physical device and control it. At the time of writing, there was a USB driver and several people were expressing interest in writing a similar SCSI driver.
Other types of devices can be controlled by a userspace driver, with some help from the host kernel. PCI devices, for example, can have their I/O memory mapped into the address space of the userspace driver, which can then directly read and write the device memory. There would need to be a stub driver in the kernel to do this ioremap and to do a few other things, such as probing the device, converting device interrupts into SIGIOs to the userspace driver, and possibly doing other things which need to be done in the kernel for some reason. Given such a stub, a driver in UML would have enough access to the device that it could be developed and debugged with confidence that it would work when put into a native kernel.