tl;dr– It's not actually a true-random generator so much as a physically-sourced-random generator. The underlying physical processes can have patterns that compression helps to strip away, improving the quality of the generator.
In context, "true" randomness is referring to randomness sourced from physical phenomena in contrast to pseudo-randomness sourced from deterministic algorithms.
My suggestion would be to not take the terminology overly literally: it's not really "true" randomness (or else it shouldn't be viably compressible in the first place) so much as physically-sourced randomness.
The compression actually helps improve the generated randomness. Fundamentally, compression works by identifying patterns and redescribing them more concisely, so, by compressing something, you strip away predicable correlations. In principle, any theoretically optimal compression algorithm would ensure (actually) true randomness – being a major reason for compressing data before encrypting it.
Three reasons for compressing the raw data stream.
There're 3 big reasons to compress the data stream:
There's more raw data than entropy.
It's difficult to properly bin entropy into independent outcomes.
Entropy's subjective, and an attacker might model it better.
Reason 1: More raw data than entropy.
Say you're generating random data using coin flips.
If it's a fair coin, then each flip has an entropy of
$$
\begin{alignat}{7}
H
~=~
& - \sum_{\forall \text{outcomes}~i}{\left(P\left(x_i\right) \log_{2}{\left(P\left(x_i\right)\right)}\right)}
\\
~=~ &
- \left(
\frac{1}{2} \log_{2}{\left(\frac{1}{2}\right)}
+ \frac{1}{2} \log_{2}{\left(\frac{1}{2}\right)}
\right)
\\
~=~ &
1 \, \mathrm{bit}
\,,
\end{alignat}
$$
meaning that there's $1 \, \mathrm{bit}$ of entropy.
However, biased coins generate less entropy per flip. Using the same equation as above for coins with a bias towards landing Heads-up:
$$
{\def\Entry#1#2{ #1 \% & #2 \\[-25px] \hline }}
{
\begin{array}{|c|c|}
\hline
\begin{array}{c}\textbf{Odds of} \\[-25px] \textbf{Heads}\end{array}
& \begin{array}{c} \textbf{Entropy} \\[-25px] \left(\frac{\mathrm{bit}}{\mathrm{flip}}\right) \end{array}
\\ \hline
\Entry{50}{1\phantom{.000}}
\Entry{55}{0.993}
\Entry{60}{0.971}
\Entry{65}{0.934}
\Entry{70}{0.881}
\Entry{75}{0.811}
\Entry{80}{0.722}
\Entry{85}{0.610}
\Entry{90}{0.469}
\Entry{95}{0.286}
\Entry{100}{0\phantom{.000}}
\end{array}
}_{\Large{.}}
$$
So unless you have an ideal fair coin, you'll have less entropy than flips.
Reason 2: Difficult to properly sort entropy into independent bins.
Say we want 2 bits of entropy, so we flip a coin with a known bias: it'll land on Heads $50.001 \%$ of the time, for about $0.9999999997 \frac{\mathrm{bit}}{\mathrm{flip}} ,$ or about $3 \times {10}^{-10} \frac{\mathrm{bit}}{\mathrm{flip}}$ from perfect.
Flipping the coin three times would give us almost $3 \, \mathrm{bits}$ of entropy – more than the $2 \, \mathrm{bits}$ that we wanted. But, unfortunately, 3 flips wouldn't be enough.
The problem's that we can't bin it. There'd be 8 possible outcomes of 3 coin flips,
$$
{
\begin{array}{ccc|c}
\text{H} & \text{H} & \text{H} & h^3 t^0
\\[-25px]
\text{H} & \text{H} & \text{T} & h^2 t^1
\\[-25px]
\text{H} & \text{T} & \text{H} & h^2 t^1
\\[-25px]
\text{H} & \text{T} & \text{T} & h^1 t^2
\\[-25px]
\text{T} & \text{H} & \text{H} & h^2 t^1
\\[-25px]
\text{T} & \text{H} & \text{T} & h^1 t^2
\\[-25px]
\text{T} & \text{T} & \text{H} & h^1 t^2
\\[-25px]
\text{T} & \text{T} & \text{T} & h^0 t^3
\end{array}
}_{\Large{,}}
$$
giving us 8 different outcomes:
1 $h^3 ;$
3 $h^2 t ;$
3 $h t^2 ;$
1 $t^3 .$
To get 2 bits of entropy, we'd want to sort all possible outcomes into $2^2=4$ bins of equal probability, where each bin represents one possible random-result stream: $\left\{0,0\right\},$ $\left\{0,1\right\},$ $\left\{1,0\right\},$ or $\left\{1,1\right\}.$ Then once we're done flipping, we select the bin that contained the observed outcome, yielding the corresponding random-result stream.
Reason 3: Entropy's subjective.
In real life, we don't have fair coins or even coins with known, uniform biases.
For example, say you're going to generate random-data with a coin. How would you even do that? Probably best to start out by flipping it a ton of times to try to guess its bias, right? And then start using the coin to produce random-data, assuming the experimental bias?
What if an attacker knows more about modeling coin-flips than you do? For example, what if coins tend to wear unevenly, or people/machines who flip coins shift their behaviors over time, in a way that an attacker knows about but you don't? Or what if the attacker just watches you flip long enough to get more data than you got before starting to use the coin?
Such an attacker would predict different likelihoods of coin-flip outcomes. They'd calculate different entropies, and presumably find any fine-tuned binning strategy you'd construct to be imperfect. Perhaps they'd find a way to exploit that imperfection to crack whatever secret you were trying to hide under a random-oracle assumption.
In short, this is the third problem: that while we can do the math to fine-tune our processes if we assume that we know the underlying physics perfectly, that's not how the real world works; attackers can treat your own random-data generation as experimental trials to do science on your underlying physical system to better model it.
Fixing these 3 problems.
So we've identified 3 problems:
Entropy-per-trial can be less than ideal, meaning that we can't generate as much random-data as experimental-data.
Binning possible outcomes can be lossful, generating less entropy than a naive calculation would suggest possible. This requires generating even more data, and even then binning might not be perfect.
All of these models are empirical and imperfect; a dedicated or advanced attacker might be able to model the underlying physics better than the random-data generator, breaking the random-data-generator's assumptions.
In short, the output from a "True" Random Number Generator (TRNG) (a term which I really dislike, but that's another rant) can be insecure before it's been compressed.
These compression methods fix these problems (in a practical sense, anyway).
By reducing the random-data produced to be more in line with experimental entropy, the idea that the random-data represents "true" entropy can seem more plausible to some.
The cryptographic hash functions guard against attackers trying to back-calculate anything.
Ultimately, it's a clumsy process that probably isn't quite as robust as one might like to imagine, but it gives everyone what they want. Folks who want to believe that the random-data is truly independent are enabled to hold that belief by the seeming plausibility of having the entropy of the experimental source while folks who want random-as-far-as-anyone-can-tell data can be provided for by the power of cryptographic hash functions.
Summary.
There're a lot of theoretical problems with common practices in generating allegedly "true" random data, but lossfully cryptographically hashing everything makes it work.
So your source probably meant that the experimental-data produced by the physical process was insecure before the lossful cryptographic hashing (which they referred to as "compression"). But it's that step that's meant to smooth over all these issues.
