I don't think that application behavior would be a good source of entropy, since it is, at least in theory, predictable. The others are probably good, although you need to be sure to only use the least significant bits, and make sure that the sensor doesn't have some weird behavior which makes the least significant bits predictable somehow.
If I had to hazard a guess, I'd say that this isn't often done simply because computers didn't typically have a lot of sensors until recently, and now you're likely to have a good-quality dedicated hardware random number generator built in, e.g. Intel's RDRAND instruction.
> I'd say that this isn't often done simply because computers didn't typically have a lot of sensors until recently
I thought it was done a lot, for example, in the Linux kernel: "The random number generator gathers environmental noise from device drivers and other sources into an entropy pool." [1]
Indeed, although as the man page describes, /dev/random is too slow for most practical purposes. The entropy pool drains rather quickly and then the device will block while the pool refills.
If I had to hazard a guess, I'd say that this isn't often done simply because computers didn't typically have a lot of sensors until recently, and now you're likely to have a good-quality dedicated hardware random number generator built in, e.g. Intel's RDRAND instruction.