Why is COM interop preferred over P/Invoke in .NET?

PInvoke is a very nice tool, but it certainly is no substitute for COM. PInvoke only supports simple functions with a C syntax; COM lets you implement an object model. Take the classes in the Microsoft.Office.Interop namespaces for example - they are all pure COM classes with no wrappers. Doing Office interop with PInvoke would be excruciatingly painful.

Another core problem with PInvoke is that it is typically the burden of the client programmer - the person least likely to get them right - to write the declarations. A COM author can publish an auto-generated type library, much like metadata in a .NET assembly, drastically eliminating the odds for mistakes and no work needed by the client programmer beyond Project > Add Reference.

Addressing your bullets:

• checked out code will always use the correct DLLs instead of the last registered COM
  You are still subject to the vagaries of Windows finding the proper DLL. The only good way to avoid accidents is to store the DLL in the same directory as the EXE, which is quite possible in COM as well; all you have to do is create an empty file with the name yourapp.exe.local

• Multiple versions can run side by side on the servers (for instance: DEV, TEST and QA)
  Not a problem in COM either, using the above technique or by using a reg-free manifest.

• No more COM registrations hassle
  Use a reg-free manifest so no registration is required. Very simple to do - just set the Isolated property of the reference to True.

• Much faster than COM communication (articles I read indicate a 30% speed increase)
  It is much slower than COM. You can incur an extra cost by making late-bound COM calls through IDispatch; that's roughly as expensive as using Reflection to make the call.

There's a third way to do native code interop: writing a ma