This subject causes a lot of controversy, as you’ll see if you read the mailinglist archives. Take a look at the following two threads:
http://discuss.develop.com/archives/wa.exe?A2=ind0007&L=DOTNET&D=0&
P=68241
http://discuss.develop.com/archives/wa.exe?A2=ind0007&L=DOTNET&P=R6
0761

COM is about introducing type into components, period. The primary theme
of COM was that we loaded code based on types (CoCreateInstance) and that
we resolved entry points based on types (QueryInterface). This was a big
advance from the days when we loaded code based on files (LoadLibrary)
and
resolved entry points based on flat symbolic names (GetProcAddress).
Nothing in CLR changes that. The context architecture of MTS made this
loader extensible, allowing aspects of your implementation to be expressed
via declarative attributes as well as executable statements.
Where classic COM has always fallen short was in the area of runtime type
information. In classic COM, the TLB describes the EXPORTED types only.
IMPORTED types are opaque, as are INTERNAL types used within the
component boundary. The former makes it impossible to perform
dependency analysis for deployment, versioning, etc. The latter makes it
impossible for certain classes of services to do anything useful without
massive programmer intervention. Thankfully, CLR provides the system with
“perfect” type information, which as you well know, enables tons of goodness
from both MS and third parties.
Focusing on things like GC or IL/JIT performance is really a red herring, and
it looks like you have avoided that trap. Your comment, however, really cuts
to the chase in terms of the “soul of COM” – that is, the role of the interface.
In classic COM, all object references were interface-based. In CLR, object
references can be either interface-based or class-based. Yes, many of the
folks at MS now advocate using classes in many of the scenarios where
interfaces were used in the past. In the intra-component case where
incremental deployment is a non-issue, this shouldn’t seem so radical, as
most of today’s COM components use class-based references internally (most
ATL programmers work this way, I know I do). In fact, I am personally glad
that the same technology I use for loading cross-component types is used for
intra-component types. This solves tons of the old VB “New vs. CreateObject”
bugs that today’s COM programmers still battle.
For inter-component sharing of class-based references, the water is more
murky. On the one hand, if you look at passing class-based references as
parameters, your aren’t that far off from passing structs, and as long as you
stick to sealed, MBV, class definitions that are immutable, this should be
pretty easy to swallow. The more problematic case is where abstract classes
are used in lieu of interfaces. Personally, I am still skeptical about this one,
but I see (but don’t necessarily agree with) the arguments in favor of the
approach. As is always the case, the community at large figures our which
parts of a programming model make sense and which don’t, so I am willing
to be proven wrong. As far as I can tell, none of the ideas worth keeping
from the IUnknown era have been dropped. Rather, the big four concepts of
COM (contexts, attributes, classes and interfaces) simply have a better
supporting implementation called CLR, which until not that long ago was
called “COM+” (run REGASM.exe and look up your code in the registry

So, is CLR COM? If you think COM is IUnknown and a set of APIs, then the
answer is no*. If you think COM is a programming model based on typed
components, interfaces, attributes and context, then the answer is yes. I fall
firmly in the latter camp, so to me, CLR is just better plumbing for the same
programming model I’ve spent years working with.
The bottom line is that .NET has its own mechanisms for type interaction,
and they don’t use COM. No IUnknown, no IDL, no typelibs, no registrybased
activation. This is mostly good, as a lot of COM was ugly. Generally
speaking, .NET allows you to package and use components in a similar way
to COM, but makes the whole thing a bit easier.