I wouldn't say there is any threshold where purely functional programming shines less. Fewer regressions and the system being more likely to "just work" makes it more fun to develop. So for interactive programs, servers, CLI tools, parsers et.c. purely functional programming is amazing. An elm developer reported that the prototype they wrote in elm ended up with less bugs than the actual production system. I personally experienced building a system and after I had written a few thousand lines, fixed all compiler errors and then it compiled and was just... done. No bugs where found in production.
In F#, an experience report came out where 350k lines of C# were rewritten in 30K of F# code. They also went from 3k null checks to 15 lines of null checks (Plus much more). Zero bugs were reported in the newly deployed system.[0]
Now with that said, there are exceptions where purely functional programming languages shines less:
- Places where the ecosystem is not quite as mature. If you're building a server and have to interact with Cloud services in Haskell, you'll have a bad time.
- Any kind of system where you need to do manual memory management, so systems programming, is badly suited for purely functional programming.