a measurable advantage of c# over java is LINQ.
It leads to (in my opinion) grotesque, unreadable code that more often than not hides enormous performance problems. It offers so much expressiveness, seemingly so innocent of its cost, that it gets massively overused and abused.
As with all things in languages, one can argue "use it right", "don't work with bad programmers", etc, but I have found this to be a universal issue across a number of shops that I've been brought into: If the project uses LINQ to any degree, enormous performance problems almost always come along for the ride.
Often this simply doesn't matter, hardware or low utility masking the problem. But when it becomes a problem, and it is endemic across the solution, it requires major reworking.
So I say write slow code so you can find what's slow early on. The problem is likely to be in the architecture and data structures rather than in the processing code. If Linq gives an opportunity to deliver a working example quickly, and that example shows that for large N the perf is horrible, then Linq was extremely useful! Change some collection type, demoralize something, add some caching etc. and then slightly adjust the Linq query to suite. Large query methods are inertia to such changes so when they DO become necessary it's a larger effort.
Note that I mean Linq to objs now not Linq to Sql or some other provider.