> He also basically ignored Macintosh and ObjectiveC
At Backblaze (my company) we write all lower level common libraries in 'C' and C++ so like a cross platform HashTable, and file I/O functions. It turns out ObjectiveC on the Macintosh is a PERFECT SUPERSET of 'C' and C++ so luckily all the Objective C code can call into our OpenSSL for encryption and can call into our base libraries for File I/O.
UCS-2 made a lot of sense back in the day when Unicode was supposed to be 16-bit and you'd just have one 16-bit "char" for each Unicode code point. Bliss! Then Unicode breached the BMP and this didn't work anymore. UTF-16 is just a way to let all that old code that assumes 16-bit Unicode to keep working. You get all the disadvantages of UTF-8 (no 1:1 correspondence between code units and code points) and none of the advantages (widespread compatibility with non-Unicode-aware tools, mostly-reliable discrimination between actual text and random binary data that might look like text).
One can kind of make a case for UTF-32 in some cases, but UTF-16 is almost never the right choice unless there is literally no other.
It sounds like you have it figured out, but just in case: UCS-2 is the original pure 16-bit encoding from the days when nobody could conceive of needing more than 65536 characters for anything. UTF-16 is the hacked up "oops, it turns out there are a lot more Chinese characters than we realized" version that tries to maintain some compatibility with software built for UCS-2.
Given that there was only a five-year period between the first release of Unicode and the introduction of UTF-16, it's kind of amazing how pervasive the 16-bit encoding got. It's thoroughly baked into Java, where "char" was supposed to be a unicode character, but ended up being a unicode character or a piece of a UTF-16 surrogate pair. Windows APIs and Cocoa's NSString went through the same process. JavaScript too, and the spec still allows implementations to only support UCS-2.
This is why we do not use wchar_t as a cross platform type. We like "char *" with NULL terminated Utf8 strings, which works really well on all platforms. Unfortunately on Windows, some of the core API still take Utf16 (2 bytes per char). Since it is a Windows call it must be in an #ifdef anyway, and so IMMEDIATELY BEFORE calling into the Windows call at the last possible moment we convert the string from Utf8 to Utf16. It sounds like a pain, but after you have wrapped all your OS specific calls (like File I/O) you're calling the higher level anyway, and it was completely worth it.
It's very, very hard to make any generalization about programming, and so I suspect that in his confident pronouncement that cross platform should never add more than a small amount of time to a project, there is something he's ignoring. The application they sell is for backup, and so it would probably be close to ideal for making cross-platform. I think he underestimates how complex GUI code can get when dealing with requirements less trivial than a backup application.
He also basically ignored Macintosh and ObjectiveC. I don't recall what the state of Macintosh was at the time this piece was written, but I'm pretty sure ObjectiveC was the standard language on Mac then as it is now.
I think there are sage principles here, though.