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.