That's a gross overgeneralization. For example, there might be no unneeded operations in a particular case, or sufficiently few that it's not worth doing them lazily. (Lazy computation is often more complicated to implement.) Or the result of the common work could be so large that caching it is impractical. For example, let's assume we have a program that extracts information from large images and then does something with it. There are different kinds of information, and not every run needs everything. However, a part of every single information retrieval would be to transform the image into a different form (e.g. decompress). Because the image is very large, caching that different form might simply be impractical, especially if the memory is needed elsewhere. Or you might have enough memory to cache the image, but CPU cache locality still says it's better to do only one scan over the image data and incorporate the retrieved information into several computations at once. So it's better to compute all information at once, eagerly.
In CornedBee context, do things lazily is much better than eagerly because "No time is spent on UNNEEDED operations" while "Common work gets repeated" can be solved using caches.