I find that when I use xml-rpc, i use structs more and more.
I'm using xmlrpc for an astronomical control pipeline. Since I have control of both ends, I define a body struct(besides a header and data struct(for transporting c structs, the latter)) with arbitrary key value pairs, and an opcode and msgtype unsigned int at the top level.
This works surprisingly well, and lets the astronomers use python or perl in really simple ways, which is the main benefit of xml-rpc over REST. For them, the URL is essentially opaque, an all they care about is the opcode and body really, eg. opcode=TAOS_DOME, body: observatory=A, open=1.
On the other hand, for more explicitly web oriented apps, i find a clear need for more descriptive URL's, no matter what underlying protocol I use. REST's insistence on not using methods in the URL makes me have to carry method names in the transported xml, independent of the underlying protocol.
At the end of the day, extensibility depends on how well you write the underlying server. Extra params can be carried as structs in xmlrpc, or in the xml document in document-oriented SOAP or REST. The lesson for me has been to let this transport payload be loosely defined, no matter what my protocol..