Electronic – SPI on ATtiny13

Yes, very easily. In this scenario, RESET works as the active-low slave-select. The programming algorithm is very well documented in every AVR datasheet (look under Memory programming, Serial Downloading).

Note however that some AVR chips have their ICSP SPIs on different pins than their regular SPIs (for example, atmega128 shares the ICSP SPI with one of its USARTs).

It's not a very probable error, and the consistency of this "wrong" ID may be telling. Bad connections can cause some glitching, but usually in the form of lagging bits (i.e. showing values neighboring bits are), and 94 vs 90 doesn't look like that. Further, a quick search in avrdude's list of AVR IDs shows that the ID you get is that of an ATmega168, common on Arduino. Furthermore, the Arduino bootloader speaks the STK500 protocol, which your avrdude is using here, so the obvious question is what your programmer is?

I'd guess you may have something like an Arduino set up as a programmer to program other AVRs, and when it happens to be resetting (and thefore still in the bootloader, which has a timeout before starting the loaded program/"sketch") as avrdude is started, you get to reprogram that AVR instead of the next board.

My second guess, which would be the first without the above notes on Arduino behaviour, would be talking to another programmer unintentionally; that can be affected by simple things like the order they are connected to USB.

In either scenario, it's not actually an incorrect ID, but another AVR than intended responding. For the Arduino as programmer case, things can be complicated by automatic reset when you start a program to talk to the board; working around that might be a bit more complex, and my first guess would be something like (sleep 3 ; avrdude -P /dev/ttyUSB0 -c stk500 -p t13 -U ... ) < /dev/ttyUSB0, which would ensure a delay between opening the serial port and running avrdude.