You don't even have to use LINQ at all with C#, it's an extension library and not one that needs to be referenced or is even included as a default namespace. LINQ is very convenient to use on in memory objects where there's no noticable performance hits. Even LINQ->SQL produces somewhat optimized SQL. How else would you bend data into shape without an ORM layer? Writing custom stored procedures, adding a whole bunch of new service methods, or manipulating data tables directly?
This 'cancer' is simply a data layer; if you use proper design patterns and seperate your layers correctly, you can surgically remove this tumour and replace it with another ORM.
LINQ is indeed optional, but this discussion is about the evolution of the language, with LINQ being held as an improvement. And because it is new and shiny, C# code across the globe quickly became infected with it.
Your comment on "where there is no noticeable performance hits" strikes a chord because when first used there are no noticeable performance hits. But then that application grows and scales and suddenly it is death by a million paper cuts, thousands of grossly inefficient set operations devastating performance. That's aside from the fact that LINQ is often a short-circuit saving from having to think about appropriate algorithms of object-methods to deal with the likely uses.
This 'cancer' is simply a data layer; if you use proper design patterns and seperate your layers correctly, you can surgically remove this tumour and replace it with another ORM.