If option 2 is relatively easy for you (like adding one-line JSON conversions in your back-end controllers, for example), then it’s probably a good investment, as the JSON is leaner over the wire, far less work on the client side and generally preferred by RESTful API consumers (in case there are other consumers).
Having recently done this kind of work, I’d say the next best path (if option 2 is difficult) would be to use response and request transformers to perform conversions between your XML and JavaScript objects, which is a variation somewhere between your options 3 and 4. The DOMParser object is native code, so it parses XML plenty fast. Transforming the XML DOM to JavaScript objects and generating XML from JavaScript objects are both fairly straightforward recursive algorithms. This approach decouples all of the rest of your client-side code from the back-end representation, which would not be the case if you went with your option 1. Such decoupling would allow you to make direct use of a JSON-based RESTful interface, should such an opportunity arise.
Selecting any option that involves JSON/JavaScript objects will often involve dealing with impedance mismatch issues like XML attributes, XML collections vs. JS arrays and XML mixed content representation. If your data models are simple enough, or you don’t mind living with the solutions provided by out-of-the-box transformers between XML and JSON (e.g., redundant object containment, numbered text properties to represent disjoint text mixed with elements), then this may not be an issue for you. Otherwise, there are opportunities for customizing transformation behavior at either end of the request imperatively (though sadly not declaratively, as far as I’ve seen).