The author doesn’t appear to consider the use of binary-only (typically commercial licensed) libraries. There’s still a need for an ABI and “modern tooling” isn’t a magic wand.
I'd guess that majority of such binary-only libraries use C ABI interfaces. The entire Windows ecosystem of COM modules works on top of C ABI's.
Until the moment when you are forced to use a third-party SDK with std:: and boost:: (yeah, WTF?) types in the interface.
Oh, and you can't avoid that, say, you are working on a trading bot and that's the only "supported" way to connect to an exchange.
In the end people usually just reverse engineer and reimplement to get rid of such cursed blob. Fortunately, it works - the vendor can't effectively push all clients to update their SDK too, so all wire protocols are infinitely backward compatible.
The last time I was forced to deal with such a proprietary SDK (that required an ancient Windows C++ runtime, and segfaulted like crazy, natch), rather than waste months reverse-engineering it, I wrapped it in a separate process and talked to it via IPC. That got the job done, and every time their shitty code locked up or crashed, I just restarted the wrapper process from the main application.
Serialized data over stdin/stdout is becoming my favorite protocol for ABI compatibility.
The amount of problems this solves is incredible, and it creates none of the ops issues with configuring and launching some new kind of Docker image.
For mummified binary dependencies, C# allows tediously fine control over stack frames in DLL function calls, and similar FFI systems are likely to be equally malleable; there's probably a blind spot towards reverse engineering in C++, due to the expectation that a random ABI should "just work".
The problem is actually not ABI, it's ODR violation. You can make it work, just make your own wrapper in C ABI, link it with whatever dependency (and version) that your vendor insists on, then `-fvisibility=hidden` and partial link the entire shit to avoid ODR violation.
People reverse these SDK partly because it makes the codebase saner, and partly because, well, this is trading, a saner implementation is almost guaranteed to be faster than vendor's bullshit one, and guess who cares about being a little bit faster than everyone else?