Direct Usage Scenarios
While we have always said that embracing Constructor Injection within an Inversion of Control design is far more important than using a container, there are many reasons you'd use PicoContainer.
Factors that are common to just about all direct usage scenarios are:-
Mutiple implementations of a type
You have a need to support multiple implementations of some component type (as simple as a single class) with potentially very different constructors. The only assumption PicoContainer makes is that all component implementations are designed using Dependency Injection (Constructor Injection or Setter Injection). It could be that all of the implementations are in your codebase already. It could be that some are in your codebase and some are going to be written by others (refer to the Plugin pattern)
No forced choice of metadata for plugins
It would typically also be true that you did not want to expose your plugin community to an API that is not part of your product. That may include the metadata (XML, properties etc) that could be used to specify the plugin details. You're free to define your own metadata (XML or other) to define how the plugin behaves in your design. Also whether you have to go to the level of defining what dependencies are needed in that XML or not, which could be quite tedious.
Extensions & participation in component infrastructure
You want to make some simple extensions to, or optionally participate in, the component infrastructure.
Aspects, Monitoring, Instrumentation, Publishing etc are things that interest you. All transparent of course.
Indirect Usage Scenarios
You're using reusable tools that some other team has written/designed that has a plugin architecture that secretly uses PicoContainer to handle some of its open plugin needs. It's most likely not obvious to you when you use that tool's API.
Refer to Jetbrain's Intellij IDEA, the best Java IDE.