A COM client cannot load IL directly so there's always some intermediary that loads the IL code and transforms it into native code.

With .NET Framework it was mscoree.dll which is installed in \windows\system32, is quite stable, and ships with Windows for quite a time now I think. So it's common to all .NET Framework COM (in process) objects

With .NET Core, there's a native host that, unfortunately or not, must be shipped with the project, it's called [project].comhost.dll.

The "Any Cpu" / "x86" / "x64" choice do influences this for the .NET assemby, but it cannot support the "Any Cpu" setting for the comhost.dll, it must be x86 or x64.

Here's a small visual:

The underlying design idea is IMHO to maximize loose coupling between .NET (core) and the OS (here Windows). It definitely has some drawbacks, it's not limited to COM.

Here is a discussion on this subject on the official dotnet github: Support dual comhost.dll (x86, x64) generation for .NET Core assemblies using "Any CPU