Their answers to these two situations are that functions used frequently by only a few users can be somewhat hidden in the UI, but should be quick to use once you know where they are. Functions that are used infrequently by many users should be obvious but may be slower to use; for example, they may require more clicks. As I say, this depends on the exact nature of the application, but it’s nice to have a quick rule of thumb.
The authors’ UI Designs website contains the relevant excerpts from the book, in the UI Structure section:
To determine the priorities of the tasks for the user interface, divide the tasks into those done (a) frequently by many, (b) frequently by few, (c) occasionally by many, and (d) occasionally by few. These categories will not only tell you which features you should concentrate on making smooth and easy to accomplish, but will also suggest where they should be placed in the interface and how they should be designed.
Tasks done frequently should require fewer clicks than those done occasionally; tasks done by many people should be easier to find than those done by few. Therefore, Frequent by Many tasks should be visible and take few clicks; Frequent by Few tasks should take few clicks but may be a little harder to find; Occasional by Many tasks should be easy to find but may take more clicks; and Occasional by Few tasks should be hidden and may take more clicks.
This seems like a good way of managing the UI of a feature-laden application. Whether you actually need to include all those features at all is a whole separate issue.