It's funny, seeing all the "who uses that ancient junk" versus "don't touch ODBC" approaches.
Both views are symptomatic of the sticking-plaster nature of the design of windows. So many bits bolted together, nobody really knows what strings move when you pull on one corner.
Is it really so difficult to aim to create a small and compact set of tools? "But backward compatibility" I hear business leaders scream. Yeah, tell that to those ancient 16-bit Windows 3 applications that are still in circulation - never migrated to new tech because business doesn't want to pay for development again and again. (So I now keep VM's around for certain things).
Still, it could be worse, it could be the arcane rituals of TNSNAMES.ORA; which I've had many an amusing argument with supposed DBAs that don't understand that "My" old copy of TNSNAMES works; whereas their "optimised" one doesn't. Where the criteria is that the database application actually, you know, lets you do something.
Yes, I sit in an org with a load of legacy cruft around. I don't know many large outfits that aren't infected by ancient ODBC or Oracle...