ICorDebug notifies a debugger when a managed class is loaded via LoadClass debug event. For dynamic-modules, this is useful because it tells you that you just baked a new type and so may have new code to bind breakpoints in (see here for debugging ref-emit).
But for everything else, this is useless. LoadClass doesn't really provide much value beyond LoadModule. For example:
Basically, LoadClass just means that the CLR "touched" the class. ICorDebugClass is a pretty anemic interface that doesn't let you inspect very much. It's possible if there were more powerful inspection methods on ICDClass that they may lend meaning to LoadClass. For example, maybe when the CLR fires a LoadClass event, internally it did class layout and could now tell you what the offsets of each field are. But since ICorDebug doesn't let you directly get field offsets, that's a mute point.
Furthermore, since LoadClass didn't have any clear semantics to preserve, there was not a clear path for how it should be extended to handle generics in V2.
The moral of the story: Don't have APIs that don't actually mean anything.