Having never used a COM bridge, or whatever, I can't really comment on whether or not it's better.
Lets put it this way.. All a COM bridge consists of is a jurry ridged solution to get "around" something scripts don't allow. Basically, all ActiveX components have two sets of interfaces:
QueryInteface - Used to get in-bound connection points, such as browser.browse "http:\myurl" or properties, such as mystatus = browser.status.
Connection points - Used to get *out bound* connections, such as OnPageLoaded.
The problem is basically this, script engines do not, themselves, give access to the later interface. Some languages and tools like MFC of VB *hide* this interface, assuming that you know, "before" the program is compiled, what objects you are going to use. But every ActiveX object/application you create has these connection systems in them, assuming you provide the correct "FireEvent(blah)" or equivalent commands in them for talking to the thing that use them.
To use the 'browser' object as an example, some place in it is code like this:
if finished fireevent (PageLoaded);
And some place in the connection points is an entry that says, "IID_OnPageLoaded". Some place in MFC is code that, if you add a 'broswer' control to your program does:
set brctl = createobject("browser")
brctl::Advise (IID_OnPageLoaded, GetRef("OnPageLoad"))
and later on, when it needs to die, does:
brctl::UnAdvise (IID_OnPageLoaded, GetRef("OnPageLoad"))
set brctl = null
Or, something roughly like that. This is hidden under the hood, where you can't see it. A COM bridge simply restores to you the ability to do the Advise and Unadvise steps yourself, so that objects you want to add "after" the program is compiled, can talk to yours.
IE and some other clients, for which engines like VBScript and JScript where developed, already "have" these bridges in them. The stand alone .EXEs for things like Lua and Python, as well as wscript, also contain such bridges. But there seems to be an assumption that a) the way they work is so obvious anyone can do it (which might be true if people coded raw COM, instead of using MFC, etc.) or that b) the script is going to be running in something that already has one, so it doesn't matter.
Basically, the functions needed are built into "ever" ActiveX that provides events, by default, they are just hidden from view in 90% of the situations where people write code. :( And yes, imho, they should work better, if for no other reason that they are part of the same system you are already using to create and talk to the ActiveX programs in the first place.