No one there mentions symbol scrambling, and how it makes C++ libraries unportable across multiple compilers for the same platform.
From a purely practical standpoint, the lack of an ABI is the #1 reason I don't bother with C++ anymore because chances are pretty good that I'll want to interface the lower-level code with something like Python or Go, both of which integrate with C code much more easily than C++.
C implementations have a standard ABI, because they usually are the operating system ABI.
So each vendor comes up with its own library format and tricks how to make the language usable in dynamic libraries. And as far as I know, they seldom talk among themselves about common ABIs.
C ends up being used as universal ABI, because in the end all implementations that generate native code need to interface with the operating system, which usually is developed in C.
But this was not always like this. Before C won its place as system programming language outside the UNIX world, there were other systems programming languages in use. On those systems there was no C ABI as such.
The Pascal calling convention ABI exists, because on the early 80s a few operating systems were developed in extended version of Pascal, like the first MacOS, for example.
Usually you are only able to link to libraries compiled with the same compiler. The same way as it happens to C++.
Also, to answer your question: Java, C#/Mono.
I forgot about that, as I was thinking about compilation directly to native code, as I wrote my comment.
Though I'm in doubt [haven't tested it yet] whether it would have worked had I tried to use something std::vector across functions compiled with different compilers.
Under Windows, the whole situation is a mess.
For current interesting platforms, the problem is often solved by either having no C++ compiler, or just one (e.g. the Qualcomm QDSP, which I think only recently gained a C compiler lacks a C++ compiler, and I don't imagine this changing soon).