Here is what I wrote on NetPro, wrapping and elaborating a long series of discussions on this topic(kudos to Chris Klardie for most of the input in the TDM area and David Reich on the UCCE side):
 
The skill group queue depth with different levels pertain to the world of TDM switches where the ACD will report on different skill group layer via PIM/OPC to the router and the record will be properly flagged by the router on the skillgroup level if the key is modified. 

This is always a challenge to explain when dealing with customers coming from the TDM side where they have a/some feature/s enabled to create different set of agent layers in skillgroup priority. 

To share some words from a peer on this topic: 

“The problem with using sub-skills in most (all) ACDs is that when the ACD picks the "most skilled agent" for a call type, it will overwork the highest skilled agents and often not send any calls to the lower skilled agents, which burns out the best agents faster in the call center. 

ACD vendors have developed work-arounds like "least occupied agent" in their selection routines to fix this and similar bug in their routing code. 

We actually avoid that logic trap all together by not automating any of the agent selection outside of the control of the IPCC routing script. 

Even if you enable sub-skills in IPCC, you have to route to them individually, in "detail" vs. trying to route to the "base skill." 

Assuming a basic call flow like this, with a "gold" and a "silver" skill group that the agents are skilled for, then you also have specific call types for a "gold inbound" and a "silver inbound" call. 

When a "gold inbound" call comes in, you would offer the call to the "gold" agent first using a "LAA" against the "gold" skill or a "queue to skill" pointing to the "gold skill." 

To overflow the call to a "silver" agent, we could insert another LAA node for the "silver" agent skill if the "gold" skill doesn't have any available agents -- if there was a silver agent available, the call would overflow directly to that agent. 

If there were no silver agents available, the call could be queued to both gold and silver agent skill groups -- or it could escalate in queue that during the queue loop, after 30 seconds add another queue to skill node for the silver agents. 

As you can see, there is a lot of flexiblity in what groups we send calls to -- and when. All under control of the IPCC script, visually. 

Personally, I prefer to be able to see what my calls will do vs. having an ACD hide the logic in the config of the skill or priority." 

From my prospective since IPCC do not provide such a layer queue depth or agent abilities have no particular meaning, even if something might be coming in the future on a newer Release enabling a complete different feature set, to this moment enabling different layers of skillgroups has no meaning in an IPCC world and could have impact on the scripting and reporting side causing an agent state transition not to be properly reported if the change does not occur in the default or base skill group too(hence why we always create the default skill group to get the right reporting features and enforced the documentation in that direction) as others rightfully said. 

One of the way to deal with the scenario as Andy mentioned was to 

1. Create a 'skill' per agent 
-- agent1skill 
-- agent2skill 
-- agent3skill 
-- etc. 

2. Assign each agent to their own 'skill' as 'primary' 
-- agent1 -> primary for agent1skill 
-- agent2 -> primary for agent2skill 
-- agent3 -> primary for agent3skill 
-- etc 

3. Assign agents as secondary to all but their 'skill' 
-- agent1 -> secondary for agent2skill, agent3skill 
-- agent2 -> secondary for agent1skill, agent3skill 
-- agent3 -> secondary for agent1skill, agent2skill 

This would be the recommended way to deal with this, if you decide to stay on the approach of dividing your agents in skillsets. Caveats below.
 
Caveats: 

As others said Base groups are recommended over sub-groups to avoid confusion when reading reports, and scripting. 
Sub groups are supported and will continue to be supported. 

"The caveats to sub-groups are: 
1. Sub-skill groups do not imply priority in scripting. You need to script priority in with separate nodes for each sub-group if you want to give one sub-group priority over another. This is the most common area of confusion for those new to IPCC/ICM. 
2. If you queue against the base group when sub-groups are configured, queue statistics will not be counted against the sub groups. You need to queue against the sub groups in order to get the queue reporting correct in AW/reporting and at the agent desk top. The reason is that if you against both sub-groups, calls queued would roll up as 2 calls queued in the base group, which was also confusing. 
3. When mapping services to skill groups, you can indicate which skill groups are primary members of the service, which just gets confused with the primary sub-skill concept. They are unrelated. 
4. When selecting "agent skill group" reports, the base agent skill group is available in setting up the templates, and will return no data since we only report on the agent level sub-skill groups the agent is logged into. Agents are not allowed to be assigned or log into the base group if sub-groups are available. 
5. When selecting "skill group" reports, if you select base and sub groups at the same time, it may appear that there is double counting in the summary since the base skill group is a roll up of the sub groups. To avoid this, only select either base or sub-skill groups. 
6. Each sub-skill group is pretty much treated like a separate skill group by the ICM and Router. The only difference is the automatic grouping and associated roll-ups into the base group. 

Finally on the documentation side look at 
http://www.cisco.com/univercd/cc/td/doc/product/icm/ipccente/ipcc60d/ipccent6/ipce60ad.pdf 

Page 45 

>> Note, however, that primary and secondary skill groups do not, by themselves, affect the priority given to them in an ICM routing script. 

If you wan to use subskill groups as primary and secondary skill groups, understand that primary and secondary skills alone do not guarantee routing priority. You must build that priority into your routing scripts. You can do so by including separate Queue-to-Skill Group nodes in your routing script, and placing the node that points to the primary skill group before the node that points to the secondary skill group. << 

Subskillgroup enablement: 

I think the main benefit of sub-skill groups is that it provides the ability to have a built in overflow group. 

Some set of agents would be in the primary group, if no one is available for x amount of time, the script would try the overflow group. 

In this way, you can see when a secondary agent takes a call what skill group it was meant for when looking at skill group or agent skill group reports. 

You can do this because the overflow group is specific to the skill group. 

The other way to do it is to have one catch all skill group which serves as an overflow for all skill groups. 

If any skill group does not get serviced in x amount of time, dump out to the overflow which all agents are a member of. This works functionally, but you lose a level of detail in reporting. 

If you have 5 skill groups in contact center and one catch all overflow group, when an agent takes a call on the overflow, you lose track at a skill group level what the call was intended for. 

You really can't tell which skill groups are understaffed by looking at the catch all overflow. 

Having a distinct overflow for each skill group will let you know which types of calls a particular agent took, or how many calls did or did not get handled by a particular primary group. 

You can do the same thing today by using skill groups and enterprise skill groups instead of subgroups and skill group roll ups. 

It just requires about 6 more steps to add a separate overflow skill group and then add an enterprise skill group, and then set up an appropriate report. 

With sub-groups, these steps are pretty much built in. 

Another place where I see sub-skill groups being useful is when you are trying to set up language support for different skills.