While I agree, you can get all of that FP example from the article in say C++ by liberal const-usage. So is "const-y" C++ functional programming?

It's not enough to take out the 'bad bits' - you have to put in 'good bits' too.

For example, Java collections are mutable, but enough ink has been spilled about the dangers of shared mutable state, that there are various recommended defences, e.g. make defensive copies when you return collections to a caller. Or use one of the immutable collections that will throw a runtime exception if someone tries to mutate it.

Now consider if you wanted to evaluate 3 + 5. Should you throw an exception which tells the caller off for trying to change the value of 3? No, the caller just wanted 8!

This is what's missing with the 'just make things immutable' approach to FP mimicry. I want to be able to combine collections together. The Java standard library Set<> still doesn't have union and intersection for christ's sake.

I think liberal const-usage breaks move optimizations so it's not used in practice.

Perhaps not these days, back in pre-C++11 days it was very liberally used. And something I miss in other languages, precisely because it allowed for much easier reasoning.