Moving this to the general horde queue, and changing title to reflect 
the underlying issue.

Well, just because you added API methods in the past that return 
objects, doesn't mean that this is correct behavior.
The point is that all API methods are exposed through the external API 
too. This indeed renders all methods that return or expect objects in 
an RPC context useless. For methods like imapOb this might be 
acceptable because using it only makes sense in a PHP context anyway.
That's a completely different story for methods like contacts/search 
though, which make a lot of sense in an RPC environment.
Wrong. The original API design always only allowed simple structures. 
There might have been an exceptions somewhere, or two, but the methods 
that you used an argument for your point of view have been added by 
yourself, long after APIs have been added or used in Horde.
Agreed, but it's the job of the API method, or at least for Turba 
internally, to convert these kind of attributes to something usable.

Huh?  How is this supposed to work?  See mail/imapOb - that returns a 
Horde_Imap_Client_Base object.  That is most certainly NOT something 
that can be returned via a JSON-RPC call.  (or mail/flagList.  Or 
mail/createMailbox).

And that is extremely concerning if you are saying that 
inter-application API calls are restricted to simple data structures . 
  That is a **crippling** limitation for a feature that came AFTER the 
original API design - which allowed PHP objects to be returned.

If you disgaree, than there needs to be a separate RPC framework in 
the future.  Or at least a separate search call that is RPC specific.

But you absolutely cannot be expected to know the structure of the 
photo data object, so at a minimum this ticket cannot be closed.  This 
needs to be documented somewhere.

Correct

Anything returned from the API should be compatible with a RPC call as 
well. Requiring logic in the returned object to access the requested 
data will not work over e.g., json-rpc calls.

Should probably return some kind of object, so that we can do things 
like data conversion from backend transparently from the calling code 
(i.e. photo information is returned in a specific array-hierarchy that 
is documented nowhere).