I'm going to argue there are no special cases that don't fit.
In a strictly mathematical sense, yes, various things are equivalent and various patterns are universal. However, that's a bit like saying you can do anything with sequencing, selection and repetition. While true in a sense, realistically it doesn't necessarily represent the clearest way to express everything. In practice, I have sometimes found that while I might build individual parts of a complicated algorithm from tools like folds, it may be clearer and easier to write the "big picture" using explicit recursion rather than trying to adapt everything to fit some standard algorithm.
As a practical example, not so long ago I was working on some code that would take some information in a certain format as input, and update a rather complicated graph-like data structure to incorporate that extra information. This algorithm involved walking the graph, and depending on the properties of each node reached and of the information to be merged in, either updating that single node "in place" or changing the structure of the graph around it. Each such step would typically transfer some of the remaining information into the graph, and then continue walking the rest of the graph to merge in the rest of the information until one or the other ran out. No doubt with enough mathematical machinations this could have been shoe-horned into some standard pattern, but in practice it was far simpler and more transparent to write a small set of mutually recursive functions that implemented the required behaviour at each step. And of course each of those functions then received information about the state of the graph walk and the state of the information being merged in through parameters.
At this point I think purity allows for laziness and laziness demonstrates a lot of the advantages of purity.
If you only care about the result of evaluating a function, sure, but if you also care about the performance characteristics of your program, I don't think it's so simple. Laziness can be both a blessing and a curse.
As for lazy with large amounts of data, Hadoop is lazy. So I'm not sure what you are saying.
In short, unrestricted laziness can cause huge increases in the amount of working memory required to run a program, until finally something triggers the postponed evaluations and restores order. As I recall, there was even a simple tutorial example in Real World Haskell that could wind up exhausting the available memory just by scanning a moderately large directory tree because of the accumulated lazy thunks.