OS X is a BSD as far as portability is concerned, but in any event is strongly POSIX compliant, and is SUSv3 certified. Part of Kemp's argument, I think, is that rather than rely on cargo cult programming practices, people should simply follow the fscking POSIX standard more closely. Rather than writing Linux software and then porting it to something else, they should write POSIX software and then make it work on Linux, etc. Usually it'll just work, because Linux, while having many non-standard interfaces, supports almost all of the standard analogs.
The elephant in the room is Windows. Compared to the differences among AIX, Linux, Solaris, OS X, FreeBSD, NetBSD, OpenBSD, etc, Windows is a completely alien dimension. The world would be much better off if more projects stopped to trying to be portable to it. It's almost always a red-headed step child in a build, and the demand seems to come entirely from developers and techies who refuse to give up Windows as their personal development environment. Instead they weigh the burden on the rest of us in the form of crappy implementations.
Supporting Windows is almost like supporting TRON, in terms of common functionality of the platform. The least-common-denominator interfaces are stuck in the 1980s, and a project makes an immense sacrifice in complexity and/or usefulness by trying to work on both. Obviously it _can_ be done, but in the vast majority of cases it probably _shouldn't_ be done.
The only standard Windows cares about is C++. They have no support for contemporary POSIX/SUS or C standards. And their fundamental approach to API design conflicts with that of Unix derivatives. I'm not saying it's better or worse, just very different. And that makes porting sophisticated software difficult, to say the least.