TL;DR
Except for the high price area of HI-IL and HP-IB the answer is no, as a single interface raises total system cost and is, especially for cassette drives, which need to be cheap, contraindicated.
The long read
Early microcomputers sometimes supported several peripherals in a 'daisy chained' arrangement, i.e. instead of the computer having several ports, one per peripheral, it had a single port, which each peripheral would pass through to the next one.
First of all daisy chained is only a special case for a bus system. The argument of having only one port (connector) also works for IEEE488.
Second, it was not just early ones using such buses. Just take USB. One port and it replaced next to all others by now.
But the Vic-20 cassette drive was not daisy chained. It had a different, dedicated port.
As it got a different interface. The VIC20/C64 serial bus devices where connected using a serial interface, while the cassette drive did need a specific because of its audio nature.
Each added port had a nontrivial cost, not just in terms of manufacturing expense but development complexity, an extra thing that could go wrong, and increased difficulty of RF shielding.
Not really. Separate ports simplified design a lot, as there was no need to have an integrated handling and an abstract protocol. This saved investment in hardware as an interface was directly controlled, well as in software due less complicated drivers.
I would expect ports to be added only when there was compelling reason.
Strictly cost and simplicity. A parallel or serial port, a mouse or joystickport is much cheaper if the main CPU drives these ports directly. Controlling them via a standardized, digital bus means the addition of this interface and a processors to each connected device.
A built-in interface, only needs its controller integrated into the computer and a port connector. When doing the same via a bus like with the VIC-20, the interface-box requires in addition to the controller a local CPU (plus RAM, ROM, etc., if not integrated) to drive the controller and another interface for host communication. This is true for any kind of device connected via the bus. No matter what device to be controlled. A serial or parallel interface got the same cost burden than a serial, a video controller or a floppy drive.
It becomes less of a 'bus tax' if the device does already need a local CPU, like for a printer, or a floppy (when it comes to slow computers). Still, an Apple Disk II had always a lower manufacturing cost (when including the controller) than a Commodore 1540 (*1). But that's a special case. In general, with such a peripheral bus total system cost is much increased.
There are only three reasons why a designer would choose such a more expensive bus over separate interfaces:
Maximum flexibility with minimum configuration hassle - that's why HP introduced the HP-IB in the first place. Beside that their devices were high end priced anyway, it allowed flexible configuration of measurement and computing equipment.
Keeping the base unit price artificial low - which fits the VIC-20
Create a lock in situation - similar here.
Today it has become different as adding a CPU to a peripheral is no big deal, and even the most primitive devices already got one.
Was there a reason it was difficult to daisy chain a cassette drive?
It wasn't difficult, but costly. To make it work with a bus, the cassette drive would have need its own CPU and interface. This would have cranked the cost up to half way to a disk drive and way beyond 150 USD (early 80s). But to sell a cheap home computer (like the VIC) some cheap mass storage was esential to make it useful. So adding a separate connector and driving the cassette with as least additional hardware as possible was mandatory.
Atari had the same issue as they (rightfully) believed that a computer cassette recorder may be priced higher than a similar audio device, but not 3-4 times as much. So the SIO connector is in fact a bastard of a dedicated cassette interface and a serial bus (*2). When operated as cassette port the serial lines are used different. Clock was not driven, but data-out carried a (square wave) audio signal when writing to cassette. For reading the recorder has a set of filters to directly convert the tones into a bitstream (*3) - which the CPU had to synchronize and decode. The whole operation was enabled by the MOTOR signal (*4). During cassette operation no SIO device could be operated interleaved (*5).
Did any early microcomputer actually have a daisy chained cassette drive?
Yes - as usual depending on the value of early.
The 1979 HP41C got in 1982 a HP-IL controler (82160A) enabling the use of a 82161A Tape Drive. Likewise the HP150 (1983) and HP110 (1984) desktop computers featured default HP-IL enabling the use of the same tape deck.
There where also (third party) cassette drives for IEEE 488 (HP-IB) - I remember one operating with a Commodore CBM (*6).
Other than that I can't remember any.
The Atari SIO did only support this in a mechanical sense as there could only be one cassette drive and that could only be operated alternating with SIO devices.
Much like the cassette docking stations for Sharp's handheld computers. Here also a generic interface was fitted with some additional lines for cassette handling.
Now, when stretching this a bit, every computer bus can be used in daisy chain fashion. Just think of the TI99/4 (literally) wide extensions or Sinclair's rucksack devices.
*1 - That Apple translated this advantage into an even higher profit is not a technical story.
*2 - More correct so it started out as a cassette port that turned into a serial bus during development.
*3 - The hardware frequency discriminator war also the reason why there where no real fast speedtape formats for the Atari.
*4 - Well, not really, as regular SIO-Devices (non-cassette that is) did not monitor the motor line. To them nothing happened on the bus as there was no clock signal. While this should have been sufficient as locking, it could lead to a very strange problem with unfinished disk operations when starting a cassette read, resulting in locking up the disk drive until a reset is send out.
*5 - Yes, of course did clever programmers find a way to write low level routines to create some parallel operation, but that was confined to very special usecases.
*6 - That setup was even more special, as it was used to control the nightly transmission of a radio station. The cassette decks (there where in the end several) weren't used for data storage as maybe intended, but to hold prerecorded shows/music and the Commodore did select which drive to operate at the right time. In the beginning it was only whole segments (a little less than 15 minutes each), later on the software got extended to select single songs of the repertoire (the collection of all cassettes in all drives) according to a classification system (they called it 'program colour') and shuffle them in random order while taking into account when a specific song has been played last time (avoiding twice the same within a few hours). But that's a separate story :))
This might be fairly standard since some years, but in ~1981 it was revolutionary.
