First of all, I am arguing for the base case: absent any studies, the null hypothesis is naturally that there are no major differences between programming paradigms.

On the issue of bug counts, there was one huge study, that was successfully reproduced [0], which finds that there is a real but small negative correlation between FP and bug counts in large GitHub projects.

For productivity I haven't been able to find any large-scale studies that compare functional vs imperative/OOP languages. I did find one small scale study [1] that found significantly better productivity for Haskell (and a Lisp dialect) vs Ada, C++ and a few others, but it was about a specific small prototype problem with just a handful of programmers participating (the Haskell program had 85 lines, the worse, C++, had 1105; and programs took between 10h and 54h to finish - hardly representative of large-scale coding). Most other studies on productivity that I could find [2], [3] didn't include any FP languages at all.

[0] https://arxiv.org/pdf/1901.10220.pdf

[1] https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.36...

[2] https://www.e-informatyka.pl/attach/e-Informatica_-_Volume_1...

[3] https://www.researchgate.net/publication/4261726_Do_Programm...

Sorting is an example, quicksort is fast since it is done in place and mutates the data instead of allocating new memory.

Very few algorithms are not faster with mutable variables.

You can look at the R data.table package. R by default is a purely functional language, and the built-in data.frame type for in-memory tabular data is immutable. That means computing anything that changes the data requires copying it all. The data.table packages achieved pretty impressive speed-ups by dropping down into C and doing everything in-place. Also makes it harder to run out of memory.

Granted, some effects like this can be mitigated with sufficiently clever language design. Haskell with lazy evaluation. I believe some compilers for functional languages will reuse memory addresses they can prove nothing else refers to, so in reality they are mutating in-place even if semantically the variables are "immutable." Heck, even Python does that with the built-in immutable types. When you assign the changed data to a new name, it doesn't actually allocate new memory and just does it in-place under the hood. In cases like that, the data isn't really "immutable." It just can't be mutated by the programmer, only by the runtime or compiler.

Of course, if we want to get sufficiently pedantic, no data is ever immutable. The law may say a ledger is append-only, but nothing is stopping an accountant from just lying. A compiler may prevent you from assigning new data to an already-existing name binding, but a compiler can't stop someone from using rowhammer or an x-ray machine or something and flipping the bits in memory anyway.