I agree. I think perhaps, a better point to make is that FP makes certain things easy, or the default, while doing it in am imperative language requires discipline, which I think is a mistake to rely on at the industry level.
It's a bit of a reductio ad absurdum, but remember: technically everything could be written in assembler. Languages and their idiomatic usage matter. Any C++ person could point out that, yeah, everything you can do in Java can be done in C++, but the fact that Java does automatic memory management still has value to many people.
Totally. And I also think a lot of imperative languages make that kind of discipline more of a hassle than it needs to be. (Giant peeve: .NET does not have any decent options for immutable collections in its standard libraries.)
But the author does bring up a good point: The industry is full of people who were taught using Scheme in university, but quickly switched to an imperative language when given the chance. Having TA'd classes that are taught in Scheme, and spent a lot of time tutoring people who fit into that class, and watching the way they go nuts when they're finally shown set! for the first time, I've come to the conclusion that it isn't merely a preference. Most of them really do have a genuinely easier time reasoning about and writing correct imperative code. It would also be a mistake to rely on a programming paradigm in which many people have a hard time functioning at the industry level.
If there's a middle ground that allows people to keep their FOR-loops while discouraging them from using mutability in the contexts where it's dangerous, that's the direction I think industry should be headed in.
It's a bit of a reductio ad absurdum, but remember: technically everything could be written in assembler. Languages and their idiomatic usage matter. Any C++ person could point out that, yeah, everything you can do in Java can be done in C++, but the fact that Java does automatic memory management still has value to many people.