If you allow a shameless plug, my "Java Content Repository - the best of both worlds" article might help understand what a content repository is.
In the JSR 283 spec, the Java Content Repository is defined as
an abstract model and a Java API for data storage and related services
commonly used by content-oriented applications.
So you could say it's a storage system that's best suited for content-oriented applications, for example as a back-end for websites. It's more similar to hierarchical and object databases than to relational databases, and we often refer to it as "a file system on steroids" meaning that it's well suited for file storage but does much more. The "related services" in the above definition are quite rich and include versioning, observation, fine-grained access control, structured and full-text search - many things that you need when working with content.
That being said, I disagree with @EJP that using multiple datastores is necessarily better - a major benefit of JCR is that it nicely integrates file storage with database-like operations and unstructured schema-less storage, without requiring the kind of hybrid system that @EJP mentions and that might be much harder to manage. Depending on your needs, more specialized storage systems might be useful, but JCR offers a lot of out-of-the-box functionality that you'd have to reinvent if you create your own hybrid storage system.