Like any protocol stack, USB incorporates components representing various layers. High-level drivers and libraries provide higher-layer functionality on top of lower layers, effectively abstracting those lower layers away and out of sight.
In the case of USB, there are a number of so-called device classes which provide standardized interfaces on top of USB, with a coordinated protocol on the host side (implemented by a driver or a stack of drivers) and on the peripheral side (implemented by firmware or drivers). Examples of these device classes include HID devices like keyboards/mice, mass storage devices such as flash drives, image storage using PTP/MTP, and so on. These abstract away the USB protocol - for example, the FAT filesystem driver used to mount a flash drive sees a block storage device and doesn't need to worry about USB framing, packetization, etc, thanks to the USB drivers lower in the stack.
In your case, the relevant class is USB CDC. The CDC drivers present a serial port to user-land programs on your computer, which can read and write a stream of data while the underlying device class host driver handles framing it and doing all the other lower-level USB stuff. Because the specification is standardized, you benefit from knowing that your application on top of USB CDC should work regardless of what vendor your CDC-compatible device is from (as long as they follow the spec), because your system's drivers are likely implemented to the spec1
Meanwhile, your application can use the serial port without needing to worry about what physical hardware underpins it. It could be serial over USB, it could be a nine-pin D-sub connector serial port implemented with a UART on your motherboard's IO controller, or it could perhaps be a serial link on top of TCP/IP.
1 or more loosely, to give leeway for devices that may not follow the spec exactly.