Is there a reason that you can't use javabin? It is more efficient than XML and should work perfectly for any SolrJ code where you are using java objects.
There could be an aspect of this that I am not seeing, but CloudSolrServer really has no need for XML responses at this time. It could be argued that allowing for a different response parser is a good idea, so I'll leave this issue open and let someone more experienced decide whether it should be closed or pursued.
The only compelling reason I know about to use XML responses in SolrJ is when you need to connect to a Solr version running a different version of javabin. The javabin version changed from 1 to 2 when Solr 3.1.0 was released, in order to fix some bugs. I'm not aware of any reason at this time to make javabin version 3.
CloudSolrServer only exists in SolrJ 4.0 and later, and can only be used with Solr 4.0 and later, so there are no javabin issues. Due to how fast SolrCloud (and its Zookeeper integration) is changing, I would not recommend using mismatched Solr and SolrJ versions with CloudSolrServer. Although cross-version compatibility is a strong goal with SolrJ, SolrCloud is under pretty heavy development.
LBHttpSolrServer is a little different. It's been around forever, so the javabin incompatibility could be a problem. Thankfully, it has a contructor that will let you build it with a different response parser: