When I query my memory for side effect free languages only Haskell comes up. I'm not too deep in the function programming community, so there could be a lot more, actually. But nevertheless I think that the existing code base and current usage is heavily dominated by languages that allow side effects.

So the question with or without side effects is currently more an academic one. It might be the next big question tomorrow, but IMHO it's not yet today.

I agree with your reasoning and your conclusion. However, if we're talking about the first programming language for someone starting right now, the future is a good time to consider. Should we be preparing people to join the workforce with what's hot now or prepare them for the future?

The great thing about side-effect-free languages is that they are much easier to parallelize. Since that's a key issue in the near future of programming even on PCs, it might be worth considering fitting the languages to the issue.

Threads, multiple processes, and other explicitly parallel methods will obviously continue to have a place. Learning to program without side effects, though, teaches one to limit side effects in assignment-based languages. Objects actually can have a role to play in concurrency, since with proper planning and following certain caveats one can have side effects within the object so long as they don't propagate between objects.

Since programs in most languages with little or no side effects can be made concurrent implicitly by the compiler and libraries, the new programmer doesn't even have to realize that it's happening at first, let alone why or how.

The basis of the assignment based languages vs. the languages without side effects issue for a first programming language goes beyond mathematical purity and regularity of (often lack of) syntax. A big part is how much you want to tilt future programmers towards concurrency-ready practices from the start.