ATTiny85 won't boot if PIN2 is not pulled high
Well, I've made some headway.  I hope to update this with something more helpful though.
I don't have a digispark or even the correct Zener diodes to replicate the necessary parts of it.  However, I did install t85_default.hex on an ATTiny85 with some alterations to the hex file to place break instructions in a few strategic places.  And then I ran avarice/debugwire against it.
The basic problem is that it's trying to tune the internal oscillator against the USB frames by looking at the D- pin.  Basically, it's stuck in tuneOsccal.
988  00001d06 &lt;tuneOsccal&gt;:
   1     1d06:       b3 9b           sbis    0x16, 3 ; 22
   2     1d08:       fe cf           rjmp    .-4             ; 0x1d06 &lt;tuneOsccal&gt;
   3     1d0a:       07 d0           rcall   .+14            ; 0x1d1a &lt;countFrame&gt;
...

So if you want to avoid this, you need to compile with that feature off, and there is a feature to do that.
I have not yet run one with this feature disabled.  But I did compile t85_default once, using make CONFIG=t85_default and found it necessary to remove the START_WITHOUT_PULLUP from the first line of the t85_default/bootloaderconfig.h file.
The code mentions the existence of OSCCAL_SAVE_CALIB, which lets you specify your own OSCCAL value, assuming the factory one for the chip isn't good enough for whatever reason.  But there doesn't seem to be any guidance on how you're supposed store it or where.  Looking at the code though, if enabled, you can see it loads the OSCCAL value from just before where the bootloader starts.
A simple way to put it there without messing with command-lines and linker scripts would be to just edit the the t85_default.hex that results from building with OSCCAL_SAVE_CALIB enabled, and add an extra record for setting the osccal value at the correct address, which I guess would be 0x19FA, so:
:0119FA00XXSS
Where XX is whatever you've determined your OSCCAL value is and SS is the checksum value, or 0x100 - ((0x14 + XX) &amp; 0xFF) in this case.  Or, if you want to be lazy, put whatever you want for SS and let AVRDude complain tell you what it's supposed to be when it tries to load the .hex file.  It will report the expected value in decimal, which you can convert to hex and patch into the file, and run AVRDude again.