The long answer is: Maybe. It depends on what you're going to do with it.
A web application? You shouldn't ever be using ActiveX at all. Some complex Windows-only browser plugin or something else that requires native code? Maybe. But even then, especially if this is a mass market product, you should seriously stop and step back and take a look at what you're trying to do.
So, I guess if your customers are in some insane semi-enterprise technology wasteland with impenetrable beurocracy and inscrutable "IT security" then yea, ActiveX might be a viable solution.
I quit after the plugin was repositioned to be our main offering above a semi-decent SAAS web service we offered. All aboard he ActiveX train! "The CEO can install ActiveX on his iPad right?"
https://developer.chrome.com/native-client
If you have to do something inside a browser, Native Client is much more interesting as something that started out as a really pretty darn clever x86 hack in the way that they could sandbox all of this in user mode interestingly. It's now dynamic recompilation, but something that you program in C or C++ and it compiles down to something that's going to be not your -O4 optimization level for completely native code but pretty damn close to native code. You could do all of your evil pointer chasings, and whatever you want to do as a to-the-metal game developer.
-John Carmack, OculusVR [1]
Nowadays there is no legitimate reason to use ActiveX. Ever. Static web pages should be coded in RoR/Java/ASP.net, dynamic-type pages should integrate jQuery/AJAX/JSON, really dynamic pages and games go into something like NaCl or (ugh) Flash.
Microsoft makes a C# library that handles MS Office API interop. If that were the task I'd look at a .Net desktop application - or an applet-type arrangement of some kind. Dropper page + .Net application? Dropper page + Applet page that communicates to a .Net wrapper layer? Silverlight maybe? Something like that.