He's saying that Apple betrayed trust by implementing secure feature insecurely (while claiming that it was working correctly) and when they decided to actually do something about it, they just quietly pulled out the rug from under their users. There was no Apple announcement or apology. Just a checklist item burying deep in a list of changes in an OS update. That's why he says 'double betrayal.'
This may sound like a stretch, and Apple themselves have decided that it's not sufficient, but while the files themselves my not be encrypted the filesystem of the iPhone itself is protected from all but deliberate (and possibly illegal) fiddling by third-parties. In this way it's not completely dishonest for the iPhone's exchange client to report to the Exchange server that the local files are secured.
Like I said it's a stretch, but perhaps the original implementation wasn't pure malice/ignorance on Apple's part.
Given that the limitation (the ability to handle on-device encryption) only affects pre-3GS phones I would guess that it's a performance thing and therefore not an issue on the desktop.
This article is very hard to follow in that the author will reverse position each paragraph, in one condemning Apple for releasing something that is not secure and in the next complaining when non-secure functionality is eliminated.
The Palm Pre is mentioned as an alternative but no evidence is given to indicate the same problem doesn't exist on that platform as well, and it would be interesting to know if other remote-exchange-access devices (webmail, blackberry, etc.) provide client or device-side encryption of local files.