Erm. I think here are a few misunderstandings at work.
Termcap is a descriptional database about terminal features (*1), not device configurations.
In sense of Unix terminals aren't devices, but something connected to a device. In a more general sense, Unix-devices are (*2) interfaces that can be accessed using OS measures.
It may be this basic mixup between the use of 'Device' as a generic term for some physical ... well ... device, with the notation of 'Device' in Unix. So for now, lets call them physical-device and Unix-device.
Termcap describes an application layer used on top of communication via a Unix-device for example a serial interface - but others are possible as well. The operating system doesn't care about termcap in particular or terminal functions at all. Only device parameters are handled by the driver - and not part of termcap. All it handles is I/O to/from the Unix-device. Obeying/using termcap (or not) is up to either application, which includes (hopefuly) the shell in use.
SCSI and USB are not terminals, but devices. They are handled as such by device drivers. Termcap has, as said, no role.
It feels like the question is more about device drivers than terminals or termcaps, and here about some imagined standard. There is none. The way to do so under Unix are device drivers, and they are a breed of hermits.
In sense of Unix-devices, SCSI and even more so USB are a bit special, as both are designed by default to handle a wide variety of physical-devices, concurrent, using the same interface. So this calls for layered model. A basic driver handling the USB host controller and on top drivers for either physical-device connected (*3).
And that's were one point were all the various ways of implementations come in, as some argue that handling such physical-devices is a userland issue, while others prefer device drivers to do so. It gets complicated by the fast that many of them are already known to the system under other aspects, thus it is desirable to have them look like earlier incarnations - like a USB-Serial interface plugged to USB producing a TTY device entry instead of having to be handled by some user land library.
And mass storage added another twist, as USB mass storage is handled quite similar to SCSI mass storage, thus having them look like an SCSI interface would save many hours of programming and debugging by simply letting the SCSI mass storage driver do the work.
Then again, a physical-device can as well be represented in several ways, like as a 'raw' or 'cooked' and the later even in multiple ways. All of this can be done by either a stack of drivers, or a single driver offering multiple views. There isn't a best way, not even a standard one. Every Unix and every device on its own.
So what at first looks like an easy Tower of Hanoi game, quickly runs into nightmarish Jenga with uneven sized blocks.
*1 - Much the same way as printcap is a special case for printers.
*2 - Well, devicedrivers can be made for next to anything. This is about physical devices in the primary sense used with Unix.
*3 - Including hubs, though, they are usually handled transparent by the generic USB driver due their basic nature to USB enumeration.