I made a little script which does a netload of a small assembly and then quits. Running AcCoreConsole.exe ten times with this script takes about 25 secs, so the time to start AcCoreConsole and do the netload is about 2.5 secs. I agree that that is a noticeable amount of time if you have to wait for it. (For the record, acad.exe takes about 6 secs to start up on this machine.)
You can use AcCoreConsole to handle multiple drawings, if they are loaded as "side" Databases by your app. But you can't change the current drawing in the AcCoreConsole editor. Of course, you're a lot more limited on what you can do with a side Database - your app has to do all modifications on the Database using the APIs and not the editor commands.
I think one way the time savings can occur is if you need to process a bunch of drawings and they can all be operated on in parallel. Say you have 20 dwgs, and you need to do some work on each one that takes 3 seconds on average (including the time to load the dwg). If you fire up 20 AcCoreConsoles at once, and if you have enough CPUs and memory, then theoretically the work could be done in 2.5 + 3 = 5.5 seconds. But if you did the work sequentially in AutoCAD, it would take 6 + 20 * 3 = 66 seconds. (I'm using 2.5 and 6 as the times to load AcCoreConsole and AutoCAD, respectively). That's a pretty huge savings, if your work flow can be done this way.
That said, it does seem like 2.5 seconds is a rather long time to simply start a process and load an assembly. The actual time required to create a Windows process or load a dll is typically much smaller than that, so there are probably other things going on in this case. The slow output display mentioned above may be part of it. I expect this issue will get more attention as AcCoreConsole becomes more widely used..
