When Diceware was first proposed more than twenty years ago, many of the computers that people used did not have easy access to Cryptographically Secure PRNGs. And, as noted in other answers, most people are not in a position to determine whether or not the PRNG they are using is cryptographically secure.
A Cryptographically Secure PRNG is, indeed, cryptographically secure. And so using a CSPRNG is perfectly fine for generating diceware like passwords. However, before rolling your own generator, there are other things to worry about, such as modulo bias. If you are curious, take a look at the wordlist generator used by 1Password (for which I work).
Don't fear the "pseudo"
A lot of people get scared away by the "pseudo" in "PRNG", but that is perfectly fine when you also have the "CS" for "cryptographically secure". Let me give a rough pair of definitions to help understand the difference between a CSPRNG and a True RNG.
With a True RNG, which outputs a stream of bits, if you are given all but one of the N bits, for any N > 1, from bit zero through bit N, there is no algorithm that can give you a better than fifty percent chance of guessing that one bit you were not given.
For a CSPRNG the definition is the same, with the following changes:
There is a (very large) upper limit to N (the number of bits you get).
The "no algorithm" is replaced with "no probabilistic polynomial time (PPT) algorithm"
The fifty percent becomes "really, really close to 50% but not exactly 50%." (Note that this is about your ability to guess given the N - 1 bits and your PPT algorithm.
Those are the same sorts of things that are built into other cryptographic security notions. When we say that an encryption scheme is secure we mean that there is no PPT that even on very large input or trials (but there is some limit) gives a a better than almost exactly a 50% chance of guessing a bit of the secret.
Again, this is a rough definition. A complete definition requires some more machinery in defining things like the limits on N, the time given to the PPT, and the "almost" of "almost exactly".
So a CSPRNG (as long as it really is cryptographically secure) is secure in the same way that other parts of your cryptographic should be.
Good seeds and bad seeds
Assuming that you have a CSPRNG, the difficulty is generating the key or "seed" for it. But most operating systems today have good solutions for this. (They tend to frequently reseed the underlying CSPRNG with truly random data. The reason that they don't just use the truly random data is that it is hard to get a lot of such bits quickly enough for applications that need a lot of randomness, so because the truly random bits are more expensive, they are used to just seed the CSPRNG.)
The do not
essentially take an input (like the current time in milliseconds), do some calculations with it to arrive at a bunch of digits, which should finally resemble a random number.
But you are correct that badly seeded CSPRNGs have been known to cause major security problems.
A good system won't use the current time, but may use time jitter as one of several sources of true randomness. Many systems today use specially designed components of chips that are built to produce random static. Other physical measurements used. Once the system decides that it has enough of this sort of data to munge and smooth out to get an appropriate amount of true randomness is will also blend this in with the secret state of the CSPRNG to create a new seed.
This helps illustrate why true RNGs are "expensive" in that they can't produce very large amounts of random data quickly. But they can produce enough to frequently reseed a CSPRNG, and so on modern systems, we do have access to RNGs that are safe to use cryptographically.
How can PRNGs be a risk?
With the whole "pseudo" question out of the way, I can answer the main question. There are two ways that things can go wrong cryptographically with a PRNG. One is that it is not cryptographically secure. In such cases it is possible for a polynomial time algorithm given reasonable output a meaningful advantage at guessing bits of output. The second way is for a CSPRNG to be badly seeded.
In the case of a bad PRNG (not cryptographically secure), if the attacker knows enough output (say it appears in non-secret nonces, initialization vectors, and other output) then the attacker can gain a meaningful advantage at guessing the secret output.
This can lead to reducing the search space for generated keys to a small enough size that it is practical to do so. Indeed, for some PRNGs knowing a small chuck of output can give you complete information about what the generator produced before and after that particular chunk of output.
In other cases, the CSPRNG may indeed be cryptographically secure, but badly seeded. If the seed is chosen from a small, somewhat predictable range, such as seeding with the time or seeding with a 32 bit value, then the attacker only has to search through possible seeds to recreate the state of the CSPRNG.
In either case, you can end up with the same secret being generated too many times. And typically use of an insecure PRNG is accompanied by use of a weak seed, so the attacker will have two things to use.