When you use COM exe to communicate with AutoCAD, you are running 2 applications (that is, the EXE must be running in order for the VBA code in AutoCAD to reach it), as you already know that it is "out of AutoCAD process".
If your purpose is to hide most your AutoCAD centric VBA code into the external EXE, other than business workflow requirements, which make ruuning external app to interact AutoCAD necessary, for example, running Excel to contrl AutoCAD, then this is rather bad practice:
1. the AutoCAD VBA code execution will take huge hit, like slowing down 10s of hundreds of times.
for example, you have a sub in AutoCAD VBA like:
Public Sub DoWork()
Dim ent As AcadEntity
For Each ent In ThisDrawing.ModelSpace
'' Do something with each entity
'' ...code details here
Next
End Sub
Now you want to hide the VBA code showing what is to do with the entity, you now do:
Public Sub DoWork()
Dim ent As AcadEntity
For Each ent In ThisDrawing.ModelSpace
Call MyExeServer.DoSomethingWithEntity(ThisDrawing, ent)
Next
End Sub
If the drawing has tens of thousands entities in it, for each entity process, AutoCAD has to start communicating with the exe app many times, depending what the DoSomethingWithEntity() does, but since it is very likely doing AutoCAD related stuff, that method alone executed in the EXE would need to communicate with AutoCAD back and forth many time. Thus, the VBA code execution in AutoCAD could easily slow down from a few seconds to minutes.
2. Running extra app for a simple task
3. The exe still need to be registered as COM component, thus the extra burden for every computer that need to run your "simplified" AutoCAD VBA code. Not to mention, it is very likely the EXE COM component is very likely break its version compatibility because of constant bug fixing or functionality updating, thus being required for re-registering.
Again, in my view, it is hardly worth doing things this way.