I maintain a large-ish enterprisey system, most of which is written in C#. I use the functional features of C# every day. However, I would caution you against lumping all functional features under a single heading of "functional programming" because you can look at each feature independently and decide whether you want to use it.
For me, I definitely use immutability, both in combination with dependency injection for my service classes, but also in many of my data structures. For instance, I might have a module that pulls a bunch of state from the database and then organizes it into a projection, such as a forecast of material usage. That forecast is immutable. I then (optionally) have the ability to cache that either locally in the program, or cache it to the database, but when I bring it back it's still immutable, so that data with that ID never changes, and none of the consumers of that data need to worry about it changing. In some cases that means I can safely split the further processing of that data across multiple threads rather easily.
Also, LINQ is really just a ripoff of Lisp's S-expressions, and I find it extremely useful. If I have a list of anything, and I need to manipulate it into another form, then LINQ allows me to do that without loops and with less complexity. I generally still use loops for modifying data.
LINQ is really a combination of three features: 1) functions as first-class citizens, 2) lambda expressions/syntax, and 3) closures. These are very useful on their own. Being able to take a function as an argument is extremely powerful, and being able to define a function inline when you call that method, and have it capture values from outside that function in the form of a closure -- very powerful.
That doesn't mean there isn't a use for imperative programming, but when I see a colleague filtering a list of objects with a foreach loop, I just cringe. Just use a .Where() clause! Don't be afraid of functional - use it as one more weapon in your arsenal.