Ваш C# уже «функциональный», просто позвольте ему это

Тут даже выглядит не сколько "слишком функционально", сколько "слишком похоже на Scala" (а это не совсем одно и то же).

просто позвольте ему это

Спасибо, но нет. Аналогичный код в "классическом" исполнении не занимается лишними аллокациями и вызовами через делегаты, что даёт существенно лучшую скорость и существенно меньшую нагрузку на GC:

|     Method |     Mean |     Error |    StdDev |  Gen 0 | Gen 1 | Gen 2 | Allocated |
|----------- |---------:|----------:|----------:|-------:|------:|------:|----------:|
|     Normal | 1.344 us | 0.0261 us | 0.0382 us | 0.2441 |     - |     - |    1.5 KB |
| Functional | 2.005 us | 0.0401 us | 0.0588 us | 0.4120 |     - |     - |   2.55 KB |

(результаты приведены при замене Console.WriteLine на заглушку)

I am philosophically opposed to providing such a method, for two reasons.

The first reason is that doing so violates the functional programming principles that all the other sequence operators are based upon. Clearly the sole purpose of a call to this method is to cause side effects. The purpose of an expression is to compute a value, not to cause a side effect. The purpose of a statement is to cause a side effect. The call site of this thing would look an awful lot like an expression (though, admittedly, since the method is void-returning, the expression could only be used in a “statement expression” context.) It does not sit well with me to make the one and only sequence operator that is only useful for its side effects.

The second reason is that doing so adds zero new representational power to the language. Doing this lets you rewrite this perfectly clear code:

foreach(Foo foo in foos){ statement involving foo; }

into this code:

foos.ForEach((Foo foo)=>{ statement involving foo; });

which uses almost exactly the same characters in slightly different order. And yet the second version is harder to understand, harder to debug, and introduces closure semantics, thereby potentially changing object lifetimes in subtle ways.

if (xs.FirstOrDefault() is null) { ... }

if (xs.FirstOrDefault() is {} x) { ... }

1. этот код валидно работает со структурой такого вида:
   

   class Weird : IEquatable<Weird>
   {
     public bool Equals(Weird other) => true;
   
     public override bool Equals(object obj)
     {
   	return obj is Weird other && Equals(other);
     }
   
     public override int GetHashCode() => 0;
     public static bool operator ==(Weird left, Weird right) => left.Equals(right);
     public static bool operator !=(Weird left, Weird right) => !left.Equals(right);
   }

   
   а обычные проверки на нулл — нет.
   
2. переменная `x` существует только в скоупе ифа, и компилятор при попытке обратиться к ней за пределами блока, где переменная null, ругнётся на попытку использовать неинициализированное значение. Весьма удобно

Код который с кортежем двух булов — полная хрень. Задача fizzbuzz не про то, как написать красиво или с меньшим количеством ифов. Она про то, как дальше будет работаться с этим кодом. Ответ — будет хреново, потому что при изменении одного условия (x % 4 для fizz, например) нужно будет это полностью выкинуть и написать заново.

            (x % 3, x % 5) switch
            {  
                  (0, 0) => "FizzBuzz", 
                  (0, _) => "Fizz", 
                  (_, 0) => "Buzz", 
                  _ => x.ToString()
            };