If server scalability is an issue for you, why would you want the server to have to send a load of text down instead of the "raw" data in a native form that the driver will understand? If you want to ultimately serve the data as JSON, I don't see how adding an extra XML conversion at both the database and web service sides would help. If you can send it to the client in XML, are you sure you want the format read by the client to be that closely tied to the database? That doesn't sound like a good level of coupling to me. As soon as you need to make any changes to the format, you're suddenly back to parsing the XML, modifying it and then reserializing it.
The canonical advice about performance applies here, of course: when in doubt, measure. While I strongly suspect that using XML will make things marginally slower here rather than faster, I'd certainly recommend measuring it instead of guessing.
Are you even sure that this aspect of performance is an issue? I would take the non-XML route from a design viewpoint - if you pass the XML on to the client directly, the coupling level is too high, and if you don't then XML isn't providing any significant benefit.
As for scalability: I can't see that serialization would affect how the code scaled particularly. It would allow scaling both up (a more powerful server) and out (more servers of the same power) with no additional problems. It's not like it's introducing an extra "single master" which would cause bottlenecks. If anything, I'd expect the non-XML route to be more scalable by putting very slightly less load on the database server (which can prove a hard-to-scale bottleneck). That's based on a guess that it takes more effort to serialize the results to XML than using the native wire protocol data representations though - and I suspect the XML serialization in SQL server is pretty heavily optimised. Again, I'd urge you to measure the differences (and bear other factors in mind) before committing to one path or the other.