Perhaps for documents which are intended to be manually edited in a text editor, which is hardly the use-case here. Otherwise it's just extremely inefficient because of all the parsing involved. You can't know when one element ends or another begins, or skip through the parts you're not interested in, without reading every single byte and parsing it. Your XML parser has to handle extra whitespace (which will almost never be present), various quoting options, and arbitrary attributes/tags; all "decision points" within the code that add complexity. With a TLV format like the Excel binary one, you can seek through the records without knowing what they contain just by reading the header and adding its length field to the current offset. Then when you get to the record you want (identified by a simple integer comparison), just do a length check and read into the appropriate structure. There's far less to do, far less decision points, and far less to go wrong.
Except, of course, if malicious files are supplied or they are corrupted somehow.
Regardless of XML-ness, you still have to check that the values are valid. With XML, you also have to check whether they're of the right type, because the format is so much more flexible.
You have to check if they are the right type if they are binary files as well.
It is far easier to repair and recover an xml file than a binary format.
except you have to move the rest of the data when you edit the document or you can fragment the data but the old data will still be on memory / memory mapped file / file.