There is a nifty page on MSDN that compares LINQ to XML with other technologies like XmlReader at http://msdn.microsoft.com/en-us/library/bb387048.aspx.
One thing that the page doesn't mention, however, is that you aren't bound to your decision forever and ever. For example, you might want to use LINQ to XML to run a query over your in-memory objects to produce an XElement, and then decide that you need to pass this information to a library that takes an XmlReader. This turns out not to be a difficult problem: there is a CreateReader method on every XNode (from which XElement derives), and a CreateWriter method in case you need an XmlWriter instead.
And of course you can also go the other way around: you can use the .Load and .Save methods to create and serialize XElement or XDocument instances from a variety of sources: strings, TextReader/TextWriters and XmlReader/XmlWriters.