Patterns are great but integrating a pattern into a non-existent/partially existing design is always a challenge. What kinds of patterns should be applied in which order? How to solve problems that cannot be solved by a single pattern in isolation? Answering such questions is important for being able to use patterns effectively.
Otherwise we apply patterns, but the resulting design will likely expose a Frankenstein's monster.
More important, the architecture under design may not provide the properties we need. For example, many patterns introduce a level of indirection to solve a design problem. Connecting several of such patterns in a row may, however, result in an inefficient cascade. Instead we want to combine the patterns without introducing multiple levels of indirection, but in a way such that the essence of each pattern still remains. Having said so, the application of patterns is not a mechanical task. It needs some experience to compose them to large structures in a meaningful way. Also enterprise level software architectures introduce problems just because of their sheer size and inherent complexity. These problems are mostly independent of the design issues addressed by individual patterns.
As such, I think applied patterns here would mean how the author has applied these to some of the business scenarios that one might typically come across and cannot be generalized to a design pattern.
Many MongoDB resources focus on different patterns you can use when designing your schema. While I wanted to include the "general" pattern descriptions, I also wanted to go into more detail on how those patterns appear in actual live code examples in particular problem domains (high-speed logging, ecommerce, CMS, social networking, etc.).
I suppose it's also because "Applied Design Patterns" sounds better than "Design Patterns and Use Cases" which is more or less what you get with this book ;-)