"To a person who has only a hammer, every problem looks like a nail." This is the worst-case version of the unitasker's dilemma: when your tool only really does one thing, then you have to look at the world from the perspective that function embodies, and anything that doesn't fit (however badly) you have to ignore. If you can't fit the task to the narrow purposes of the tool, you need to buy another tool to give you a new perspective and a new modality for acting on that perspective.
So, a tool for stringing together formatted words is not likely to be a great tool for producing a large, structured document, and having only such a tool available could blind the person producing the document to the larger structural issues involved: by focusing attention on font and type face and the like, it makes it not only doesn't help you see, it makes it harder to see that (for example) you've created sub-subsections that are inside sections, not subsections.
Search is a very broadly applicable perspective. If your search tool can help you search not just for specific content but for characteristics of the content (metadata and regular expressions) including where it has come from and when it got there, then instead of having a hammer and being forced to see nails, you have a protean tool that, when you need to work on a screw, becomes a screwdriver; when you need to work on a nut, a wrench. With IT data, a robust search tool could not just allow you but assist you in selecting simultaneous events when you have event logs to examine, help you find specific configuration commands when you have a "golden" config to decipher, aide you in locating all the uses of a particular system account in service startup commands.
When your problem looks like a bolt, shouldn't it bring out your tools' wrenchiness?