We've discussed this internally... AFAIK we still haven't officially released this API. It's still in the "hidden" camp. I want to make it a public API (I want all our API public) but I do listen to the various API owners. Some API owners have allowed the creation of API that they don't like very much to enable other teams inside VMware to do things... and that's one way you get hidden API. Other times, a team has made a feature but they aren't sure how to make a good API for it and they don't want to burden folks like me with supporting an API that's kind of messy.... that's another way you get hidden API.
The general motivation for hiding API is usually something like: If I put this out publicly I could get saddled with dealing with an API design mistake for the rest of the product's *life* and that's bad. So a hidden API sits in this unofficial space. Historically you look at things like what happened on the PC... and *that's* what VMware's engineers are trying to avoid by 'hiding' API. Sometimes that means interesting features don't get included with the public client libraries like pyVmomi. That's a shame, but it's a reaction to history...
... folks like myself are trying to find new ways to help VMware 'iterate' on API without necessarily falling into the same historical trap that the IBM PC fell into. We want to give you exciting new API *quickly* but we also want to avoid falling into the sand-trap of making API mistakes. It's a tough tight-rope to walk and we want to make sure to do it correctly and with as little drama as possible.
... where I'm trying to convince folks putting ESX CLI out there will be good. The Ruby bindings do this against the 'official' standard BTW, and I'm trying to forge a relationship between pyVmomi and the official API that will let us enter the fold as an officially supported API (hence, why we're lagging on some features as I talk to folks and try to win them over)