Why do we require a CSPRNG's output to be indistinguishable from true random? Everywhere I read, indistinguishability of output from true random is stated as a requirement for CSPRNGs. However nobody bothered to give the rationale for such a strong requirement.

Specifically, Yarrow and Fortuna both use a block cipher as the generator, and both limit the amount of output that can be produced by a particular key. The key is changed (aka rekey) once the limit is reached. Their reason is that since the block cipher does not generate duplicate output blocks in their design, the attacker can request for a large amount of output from the PRNG, find that there are no duplicate blocks, and determine that the output is not true random. So what?

The only information the attacker can get from this is the cipher's block size, and this doesn't weaken the security one bit. Furthermore this would have been public knowledge if the implementation was open source. I don't see how the lack of duplicate blocks would weaken our security.
We simply strive for crypto that's as close as possible to ideal. Indistinguishably is the strongest property we can demand from a PRNG/streamcipher.

It's hard to predict which non ideal properties will lead to problems at some point in the future. For example the non ideal properties that lead to padding oracles, BEAST, CRIME or the RC4 biases were known for years before they were shown to be exploitable.

Many security proofs assume indistinguishability, so if the PRNG is distinguishable, this weakens the proof. If the PRNG is distinguishable under certain conditions, even if it's a seemingly harmless distinguisher, then a proof relying on indistinguishability becomes useless if those conditions are met.

Consider a message encrypted using a block-cipher in CTR mode. This has the property that no blocks in the key stream will be identical (just like Fortuna/Yarrow without re-keying). When the ciphertext contains identical blocks, the attacker knows that the corresponding plaintext blocks were different, because the corresponding key-stream blocks were different as well.
Admittedly that's not a huge leak in most contexts, but it is a leak. It might lead to problems in some contexts, for example if the message only uses a few different values for each block.