If there is an applicable standard software API (either multiplatform like a filesystem, or a special one exposed by the OS kernel [1] ), the driver probably belongs in the Linux kernel (or in the form of a Windows driver on that platform). My understanding is that GPU APIs are an exception on Linux, and are implemented in userspace by a piece of software called MESA. You could also use the daemon approach in this case if you don't want to bother with getting a driver added to the kernel.
For a more niche device where exclusive access is acceptable and every piece of software would need to add special support for this specific type of device anyway, it's a lot simpler to distribute the driver as a library that software authors can include in their program. If there are several devices that work similarly but communicate differently, you could have one library that either includes multiple drivers, or exposes a common interface that other libraries can implement.
A downside of any approach for USB devices on Linux that isn't a kernel driver is that one or more udev rules will need to be added (as the article described). This also applies when using a device that uses a supported USB protocol, but has different IDs than the ones listed in the kernel driver.
[1] More devices fall into this category than you might expect. For example, Linux has an API for communicating with CAN devices called SocketCAN, so if you're writing a driver for a CAN device that connects via USB and exposes the full CAN bus over USB (maybe something that goes in or connects to a car), you should write a kernel driver that converts data between SocketCAN and whatever USB protocol is being used (assuming one doesn't already exist, a lot of USB CAN devices use protocols that already have drivers in the kernel). SocketCAN only exposes the raw data extracted from the CAN frames, so if you want to expose an easy way to control a particular CAN device, that belongs in a userspace library that uses the SocketCAN API under the hood.