Why does my ATtiny13 report wrong device ID?

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.

This won't answer the question asked originally but it might help other people landing here:

I used an arduino (and later bought a USBasp clone) to program an ATtiny85. This worked pretty well for a fair amount of time until suddenly, without any obvious reason, I kept getting wrong device signatures from my Attiny:

avrdude: Device signature = 0x1e010b
avrdude: Expected signature for ATtiny85 is 1E 93 0B

I always got this 0x1e010b ID and it drove me crazy. It didn't match the device signature of another AVR (see this list) and the cable connection was good. A bad connection would typically cause rather random errors, and the signals looked ok on the oscilloscope as well.

I finally found that my USB hub was the problem. The 5V USB supply voltage it delivered to my programmer was only around 4.4 V. When I attached the programmer directly to my Laptop, the voltage was between 5.05 and 5.15 V and everything worked perfectly fine again! Was probably a brown out or something related to the signal levels.

If you run into a problem with wrong device signatures:

• receiving 0x000000 or 0xffffff typically mean that either your Atmel chip is not powered or reset (properly). Also check if the programmer signal levels match the power supply level of your Atmel microcontroller (typically 3.3 V or 5 V) - best before connecting it for the first time ;)
• getting random false device signature calls for a bad cable or connection
• constantly receiving the same wrong device signature might just mean that you have connected another Atmel chip than the one you specified in the console ("-p t85" for ATtiny85 in my case) or you entered a wrong command and the programmer chip responds with its own ID (take care not to overwrite your programmer with your application code!)
• ... or it could also mean that the power supply of your programmer or your target Atmel chip is weak or too low - please check connecting your programmer to your Laptop/PC directly or try a different port and also check the power supply of the Atmel chip in your application.

Hope this helps someone :)