The source you quote says:
IIR filters can achieve a given filtering characteristic using less memory and calculations than a similar FIR filter.
As rbj says!
What the authors mean here with "memory" are the memory elements needed to store the filter coefficients (and as discussed, these might be fewer for IIR for defined-transition-width filters), as well as the "intermediate" results (state) needed to calculate the output. "Calculations" refer to multiplications and additions needed per output sample, and that's pretty much directly a function of the number of coefficients.
So, if you define a problem that is more efficient to solve with IIRs than with FIRs (typically, a situation where you need to have a narrow transition from stop- to passband), then the IIR needs less coefficients, multiplications and state storage.
Note that what the authors didn't tell you that they're looking at a specific class of problems – which admittedly is a very common class – namely filters designed primarily to match any given stopband/passband amplitude scheme. Not all filters are only designed with that in mind!
For example, if you need a linear phase response over a significant bandwidth (and that is a relatively common thing to wish for, as it leads to constant group delay), designing an IIR that's "smaller" than a FIR might become hard (or, in fact, impossible).
Also note that whilst IIRs are often composed of structures that are highly efficient in space, multiplier and flipflop usage in hardware, the same structures aren't always inherently advantageous in software. Modern processors use long pipelines, where it can be a big disadvantage for throughput if your structure is recursive – as requiring previous output of the IIR will require the CPU to necessarily wait for instructions to complete before being able to push in the next instructions into the pipeline. (There's clever approaches to minimize that problem, but they often lead to more complex code and larger machine code memory – also a trade-off.)
Then: In many cases, where the memory usage of your filter might become critical¹, there might be aspects to the overall application of your filter that make specific kinds of IIRs easier on memory or harder.
A very intuitive problem is a narrow-band anti-aliasing filter for a digital decimator: $L$ samples go in, $1$ goes out, and you need to apply a $\frac 1L$-band low pass to avoid aliasing. That filter should of course have a transition width of $< \frac 1N$ of the Nyquist band – and might thus become pretty long!
Now, the first thing to observe is that for FIRs, there's structures that can be very efficiently implemented in hardware to save a lot of coefficients – a Nyquist-$M$ filter could be the filtering approach of choice here, and those filters consist of zeros only, aside from every $M$th coefficient. Multiplying a number with zero and adding it to the output is a non-operation and can be completely omitted in hardware!
Another rather important aspect is that for FIR filters, multirate operations (i.e. decimation, interpolation) can usually be implemented at the lower rate – e.g. our $L$-decimator could be run only every $L$ input samples – drastically reducing the number of hardware multiplications needed per output sample (by a factor of $L$, in fact), and also: often allowing the filter to actually use one and the same multiplier hardware element – when implementing DSP hardware, you usually don't actually consider the number of calculations you need per sample, but the amount of hardware you need to achieve something at a given rate, and if you have multipliers that can run at the input rate, you can let them "handle" $L$ filter coefficients, rather than needing a multiplier for each and every single coefficient.
I thus do agree with the statement
IIR filters can achieve a given filtering characteristic (defined by the transition widths and attenuations) using less […] than a (under these specific specifications) similar FIR filter.
Especially, since you'll find biquads (which are essential IIR building blocks) everywhere, but you have to realize that the statement as given is a bit of an oversimplification.
¹ not saying you shouldn't generally use the optimal filter for your problem, but you often just don't and live with a engineering effort vs optimality trade-off