Is a PRG more costly than AES or any other encryption standard? I know that there are many encryption standards that take a key and sometimes an IV to produce a cipher-text (the most prominent one is AES). These standards usually involve many rounds of addition and multiplication. However, using an OTP is much easier than this. You XOR the plaintext with your pad, this is the only requirement computation-wise. However, the OTP comes with the problem of a key-stream as long as the plaintext. This key-stream is supposed to be random. My question is, is this randomness more costly than the encryption standards that are in use? Why don't we use an OTP in every case? What is the downside?
Let's say I cannot afford to use encryption algorithms, but I have a stream of data that is nearly-random. If I use this as an OTP (I know this is not perfectly random), what do I sacrifice in return? What can be done to obtain the best pseudo-random characteristics from this arbitrary stream of data, to make it as qualified as it can get to be an OTP?
A one-time pad requires a true random sequence that is as long as the material you want to encrypt. If you have a pseudo-random sequence, then you don't have a one-time pad: you have a stream cipher. If you have a stream of data that is only “nearly random”, then you don't have a one-time pad, you have a broken stream cipher.

Concretely, if the nearly-random sequence isn't uniform, it means that there are biases: certain arrangements of bits are more likely than certain others. Whenever these arrangements are aligned with a pattern in the plaintext — for example English text contains more E than J, text in most languages contains more spaces than any other character, HTML tends to have a &gt; shortly after each &lt;, … — the pattern in the plaintext becomes apparent in the ciphertext. So certain patterns appear in the ciphertext more often than chance, they will reveal patterns in the plaintext.

To generate a cryptographically secure random sequence from a source of randomness that isn't perfectly uniform, you need to pass this random source through a cryptographically secure pseudorandom generator. One of the cheapest techniques to build a pseudorandom generator is to use an encryption algorithm such as AES in a construction known as CTR_DRBG. If all you want to do is to encrypt one message, then it's simpler and cheaper to encrypt the message with AES-CTR than do use AES-CTR_DRBG to build a key stream and to use that key stream to encrypt a message.

In addition, a one-time pad doesn't help with the authenticity of the message. If the message is modified in transit, there's no way to detect it. Encryption algorithms can be combined with authentication algorithm, and the cost of doing the two together is less than the cost of doing the two completely independently. The computational cost is only slightly less, but the cost in code size or in gate count is significantly less. For example, once you have the AES block cipher, it only takes a little additional work to build an authenticated encryption mode such as GCM or CCM.