I can't be one hundred percent sure why but....
I've run into the exact same problem as you.
Seems Adobe is reluctant to keep their "open source" stuff as open as it might be.
You can still use the class regardless of whether or not you are supposed to. I've check inside the .swc file that comes with the latest stable build of the flex 3 sdk, and that class is there. I saw somewhere that Adobe may consider it a "private" class, however their own language doesn't allow them to do such a thing. I checked out the source for the SDK, and there seems to be a interesting tag named "[ExcludeClass]", which I'd guess is a way to tell the Asdoc to keep form generating anything about the class in the API. Considering if people know about it and even recommend using it its not a very good way of keeping its existence hidden, and that there is not even any documentation other than the Asdog tag inside the source file indicating that you should NOT use it, I'd say its safe to use this class. If Adobe really doesn't want people using it, it should bother documenting that it doesn't want people using it, or release a version of actionscript that allows for private class ClassName or private constructors or something.
Furthermore, I don't see anything else extremely useful for XMLEncoding/Decoding either in Flex MXML or the rest of the Flash XML API, which means in my books that there's nothing "higher level" that they want you to use instead. SimpleXMLEncoder/Decoder are, well, extremely simple, and possibly a joke next to the power in XMLEncoder/Decoder. That, and SimpleXMLEncoder/Decoder require the use of a pseudo-deprecated class XMLDocument that was replaced, according the documentation, by XML in ActionScript 3.0
So my beef is to use it. If your auto-complete doesn't find the necessary methods, just download a copy of the SDK and navigate to SDKLOCATION/trunk/frameworks/projects/rpc/src/mx/rpc/xml and find fully documented classes there. Hope this helps.
We use ExcludeClass to hide stuff from the doc so we don't have to officially support it in a future release and can yank it and not deprecate it. Usually that means we're not sure it is a good design. It is opensource in the sense that you can see the code and file patches for it, but we reserve the right to pull it without warning.
Flex SDK Developer
Adobe Systems Inc.
Hmm, be that as it may, and I suppose you are simply covering yourselves legally, even if it is yanked, I'm still willing to use it now. If it disappears from the SDK in future, it shouldn't be hard to find an alternative class to cover the same functionality.
So as a design consideration one could simply create their own wrapper class for use in their own application, and if and when the class is yanked change the inner implementation of the wrapper class.
Thank you for your quick reply however, it was annoying to find no answers to my question.