Why must we hash lot of times in rainbow tables? I don't get the utility to chain and reduce in generating rainbow tables.
Hash functions are made to not have collisions, or at least chain only 2 times so we don't return to the concept of the hash dictionary.

So why do we bother the machine to hash and reduce thousand of times to only store the latest value?
The comments attempt to answer by looking at the details of how rainbow tables work; however if you examine the problem they're attempting to solve, you can see that they would require a large number of hash computations, no matter how they operate internally.

Now, rainbow tables are a generic way to find preimages to an arbitrary function; that is, given a function:

$$Y = H(X)$$

where $H$ is a deterministic function.  Then, given a value $Y$, it tries to find an $X$ that satisfies the above equation.  It does this by evaluating $H(X_i)$ when building the rainbow table, and encoding all those into the table.  Then, given a specific $Y$, we search through the table to see if there was an $X_i$ that we evaluated that happened to hash to $Y$.

Here's the rub; the rainbow table method is generic; it does not attempt to examine the internals of $H$.  So, the obvious question is: if we give it a hash value $Y$ where we did not evaluate the corresponding $H(X)$ during the build phase, how can it work?  Well, obviously it can't.  That means that, if we build a rainbow table that covers a dictionary of a trillion possible passphrases, that means that the we need to evaluate $H$ for those trillion possible passphrases.  That is, building a rainbow table is going to be expensive, and unless we can rely on some cryptographical weaknesses of $H$ or some other special property, there isn't anything we can do about it.

So, since rainbow tables do not decrease the amount of work, does this mean that they are useless?  No, it doesn't.  For one, we need to build the table once.  Yes, that is expensive, but looking up an entry in a rainbow table is cheap. Once we've evaluated those trillion hashes, we can later reuse that rainbow table many times to attack many hashes (and we don't need to know those values when building the rainbow table).

In addition, the other obvious question is "if that's what rainbow tables do, why don't we just build a large table of $(X_i, H(X_i))$ pairs, when we get a hash, we can then just look it up.  Yes, that would work; however if we expressed that table in the obvious way, it'd be huge -- disk space is getting cheap, but not that cheap.  Rainbow tables are essentially a clever way of making up such a table, but in a way that makes the table much smaller (that is, take up less disk space) than what you'd expect.