I know that there are many encryption standards that take a key and sometimes an IV, and produces a cipher-text (the most prominent one is AES).
AES by itself is not a cipher, it is a block cipher. As such it can only encrypt messages that are exactly one block (16 bytes). You need a mode of operation such as counter mode encryption to create a real cipher. The mode of operation requires the IV. The IV just depends on the block size, not on any other property of the cipher.
These standards usually involve many rounds of addition and multiplication.
Not really. Some symmetric ciphers use addition, but more complex computations such as multiplication are generally avoided. Bit operations such as XOR, shifting and transposition are much more common.
However, using a OTP is much easier than this. You XOR the plaintext with your pad, this is the only requirement computation-wise. However, OTP comes with the problem of a key-stream as long as the plaintext. This key-stream is supposed to be random.
That's only true if you have true random number generator that supplies all the bits.
My question is, is this randomness more costly than the encryption standards that are in use?
There are speedy true random number generators, but you'd need a RNG that is inside the CPU to come anywhere close to ciphers based on AES. It is generally more costly to have a true random number generator than to use AES.
Often the random number generator at least requires whitening, which requires calculations. Sometimes the random numbers are even fed into AES to do this!
AES-NI on the Intel / AMD CPUs is currently at least 4 times as fast as the random number generator RDRAND on the same CPU's.
Why don't we use OTP in every case, what is the downside?
As you already mentioned, for a real OTP you need to distribute the key. To do this securely you would either need to use a physical, out of band solution (using sneakernet to distribute a CD).
Encrypting the key stream doesn't make sense, as you would need as many bits to encrypt the key as the size of the key.
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.
The algorithm needs to be secure. Otherwise an adversary could retrieve the state of the algorithm and use that to calculate the key stream.
The best thing to secure the algorithm is to use a stream cipher to create the key stream. AES can be turned into a stream cipher - for instance using counter (CTR) mode. There are also dedicated stream ciphers that are more lightweight, including the one in your GSM phone. Block ciphers such as AES are however more versatile.
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?
You'd use a stream cipher or a block cipher - such as AES - in a mode of operation that turns it into a stream cipher.
Fun fact: if you have a stream cipher then you can pre-calculate the key stream that it generates. Then you can have very speedy, low latency encryption by - indeed - just XOR'ing the cached key stream with the plaintext. And a relatively small key to establish.