So much of programming is patterns that exist for extremely arbitrary reasons (note: not acausal reasons, just reasons that are unimportant to the immediate problem domain one is trying to solve, or perhaps important in a way one doesn't yet know). Knowing those reasons can give you some mental hooks to hang the arbitrariness off of.
COM, which Joel mentions anecdotally at the top of the article, is a great example of that. I think the biggest challenge people have remembering why COM works the way it does is it's there to solve a problem that primarily the Microsoft software ecosystem had, which didn't show up in other software ecosystems as strongly: Microsoft had a vested financial interest in enabling developers to create closed-source binary blobs that could interact with each other via exposed objects.
Though COM is language-agnostic, most examples from textbooks of the mid-'90s era reveal the big problem it's solving: C++ was the hot language at the time, but C++ doesn't standardize name-mangling, so two arbitrary binary blobs of C++ code from two different compilers weren't guaranteed to be able to use the objects in each other's libraries. This isn't a problem Apple's software stack saw so often (Apple had fewer toolchains, so compiler incompatibility was less frequent a problem) and it was rarely a problem in the open-source OS ecosystems (if you're passing around source code instead of closed-source binary blobs, you don't care about name-mangling issues because you're building the source as a lump under the watchful eye of one compiler). But in the Windows world, with a pile of choices for compiler and a business need to support closed-source binary blobs that could expose objects, it was hell.
It's helpful in understanding COM to understand why Microsoft's ecosystem needed a way for closed-source libraries to expose objects in a language-agnostic way.
