One word before I start writing: I will simply use "OCX" for controls and ActiveX DLLs because it's convenient ;-)
I always mean ActiveX Controls (OCX) and ActiveX DLLs since the technology they are based on is virtually identical.

I do not see your point in arguing that it would be better to move away from OCX now because it's support could be dropped by Microsoft later on.

As a developer I search replacement for a compiler and an IDE that is not officially supported any more but still want to keep using external libraries that are very well supported. A lot of 3rd party OCX developers offer up-to-date versions of their controls and libraries. It's not like OCX is dead - not by any means.

If there was a VB7 that would support OCX that would mean I could concentrate on porting the source of my main app to VB7 now and deal with dependencies of 3rd party (or my own for that matter) libraries when the time comes or I have time to spare. If it would not support OCX it's an "all or nothing" gamble that costs a lot more time and money. Also there is no garantuee that all of the external functionality can be added in a reasonable timeframe (if at all).

Also: If Microsoft would drop OCX support, the developers of said 3rd party libraries would have to move on themselves and would probably provide new versions of their controls and libraries in another form that could by used by developers.

If you start removing 3rd party functionality from your source just for the hell of it you either have no budget that needs to be held (i.e. academic/hobby developer) or have more than enough money to spend for a project that could consume thousands of dollars/euros worth of developer time (depending on how much 3rd party technology you embed and how critical it is to your project) which is a luxury not many developers can afford.

Don't get me wrong: If it would be a financially viable solution I would gladly remove all 3rd party dependencies but for the forseeable future that is just not an option for me.