I gather that some people got the impression that LINQ is just reinventing SQL, while actually it goes beyond normal SQL. It's not just for database access, actually that's just one application of it: DLinq. Well, of course this depends on how you define a database. Because, let's face it, LINQ is just a way to query data sources. Whether that's a traditional database (SQL Server, MySQL, Oracle), an in-memory data structure or even an XML document (XLinq ladies and gentlemen). LINQ brings the declarative expressiveness of SQL to any data source. If you got a big array with customers in memory, you sometimes just want a sorted list of their names. In SQL that's really easy to write, but since you got this data in an array, it becomes harder to extract this data. It's doable, but isn't simply writing something like from customer in customers orderby customer.name select name and be done with it, more convenient? Don't start posting examples of Python or Ruby code in which this can be written shorter. Just trust me that there are many occasions where the SQL-like LINQ is a convenient and readable solution.
XLinq is actually more than a way to access XML data easily. It's a whole XML API that greatly simplifies the previous one. It offers a much simpler way to build XML trees for example. This is especially true if you use VB9, in which you can do this:
Dim BillTo = <billTo country="US"> <name>Robert Smith</name> <street>8 Oak Avenue</street> <city>Old Town</city> <state>PA</state> <zip>95819</zip> </billTo>
But even if LINQ was just language-integrated SQL, that would still be a good thing. This would allow for syntax checking of SQL queries at compile time, a nice thing to have.