You haven’t clarified the device requirement for entropy, so I’ll assume that it’s to participate in some sort of secure exchange over an otherwise open channel.
I think you have actually hinted at a way of quantifying things in your question, where you mentioned that a high-resolution clock could contribute up to 30 bits of CS-entropy, but this not being enough.
We’ll, if you know what protocol you’re participating in (assume TLS 1.3), then you know the requirement exists for at least 32+32 (for the ephemeral client key and the client randomness contribution) and then another 12 bytes of high-quality entropy (for the nonce in the ChaCha20Poly1305 symmetric cipher).
(Visit Michael Driscoll’s very helpful breakdown of TLS 1.3 https://tls13.ulfheim.net/ for more info.)
… so an observation in support of an argument for including weak sources: in the absence of a high-quality source of randomness, the device client can’t contribute to the shared entropy in any protocol like TLS, that has some sort of randomised IV or forward-secrecy.