It advocates (in section 3.3) developers "imagining" an abstract API, integrating other components using that API and later creating concrete implementations. This sounds a lot like what Java tends to do, leading to APIs with critical flaws in the real world, like a filesystem API without support for symlinks.
Section 3.2 claims that, to some extent, this is not a problem because unknown concepts can be interpreted as other known concepts – but interpreting symlinks as regular directories can lead to serious problems, e.g. when recursively deleting a directory tree.
Similarly, if the developer imagines something like the Win32 API and its I/O completion ports, implementing it on POSIX will lead to bad performance, just like implementing fork() on Win32, as Cygwin does.
Section 5.1 sort of acknowledges this: "Clearly, there is a limit to how far interface hiding can be taken. Perhaps truly ubiquitous interfaces, like POSIX, should not be hidden. There is also a risk that the programmer will design an external interface which cannot be satisfied by any foreign components, or which unduly strains the expressivity of the integration domain."
But what is a "truly ubiquitous interface"? POSIX is clearly not, unless you ignore Windows (for real-world applications). Perhaps the KDE developers believed that DCOP (as discussed in the article) was "truly ubiquitous"?