Document Sets provide advanced flexibility and power for
managing content. Per Microsoft, Documents Sets “are designed to manage all
aspects of work products. They provide a user interface (UI), metadata options,
behaviors, and object model elements that fill a gap in the hierarchy of
containers between documents and sites.”
Source: Microsoft TechNet
Document Sets can share metadata with their contents, making
it easier to tag and manage content. Workflows can be run on individual items
within a set, or on the Document Set as a whole (ex. treating the Document Set
as a legal case file, where once the case is closed, it is routed with all its
content to a Records Center for storage and eventual disposition).
Brought online as a feature of SharePoint 2010, the
SharePoint 2013 Document Sets continue to refine the capabilities of this encapsulation
method.
What’s Changed
- Document Set icon now appears in search results
- Folders supported, including the option to use folders
as a default document (We will discuss if a folder should ever be used
momentarily…)
- Support for easier aggregation since web parts such
as the Content Query Web Part understand and can display Document Sets
- Better developer support through Client side and
Server side API improvements
- Search directly in a Document Set

Source: Microsoft Ignite
What’s Still Missing
Per Document Set Views from the Content Type Hub: While the capability exists to configure a
view within a Document Set that is different from the view used by the library
it resides in, it is not available as an option from the Content Type Hub for Document Sets that cross libraries. For example, you may want to show more refined site columns
within a Document Set view in order to assist with findability across four separate libraries that all use the same Document Set published from the Content Type Hub.
Document Set based Metadata Filters: The capability
to filter content within a Document Set via a Metadata Filter Web Part. While
Search is great, “Finding” is better!
What’s Dangerous
Single Faceted Encapsulation Objects (aka, Folders):
The capability to add folders within a Document Set creates a huge risk of
nesting and false hierarchies. Please see “Folders
are Evil and What to Do About Them”. The intended use of a folder should be
for security encapsulation. This may add value if you need to separate content
within a Document Set via permissions, since you could create a folder named “Classified”
and then hide the folder from the view using the “Show all items without folders
” option in the Folders management section of a view. The end result is that
users will only see the content they have the rights to see/access and the
non-nested folders used for security are hidden.