I think a smaller, more-focused pitch might go over better, but I think you got there at the end. I'll share my laundry list and then some anec-data if that helps. (NOTE: I haven't had to convince anyone else on tech choices in 10 years so I might be less-helpful than I might think - but I've had other people have to pitch me, and I know what would have worked).
Laundry List
- Immutability removes a huge class of bugs.
- (like one that almost cost me $300k...more on that later)
- The type system removes another. (I find it useful to point out that people that think "Java" when they think about strong typing need to abandon that and look at Elm's type system fresh)
- Are you sure you have no code paths that pass invalid arguments to a function? Really?
- A ton of 'tests' that you write are probably a crappy substitute for types, presently.
- Ever had "undefined is not a function" or "no such method #foo on NilObject"? Never again.
- React+Redux gets you pretty close. But...
- "JavaScript fatigue" basically started here.
- Flux? Alt? Redux? Reflux? MobX?
- Oh sometimes redux-devtools have issues rendering Immutable.js structures? (this is fixed...but it's broken twice after being fixed the first time too)
- More goes here but...
- Are you going to use Flow? (you should, if you go that route)
- The stuff above each takes time to learn properly. Many on the order of a week or more, and I tend to learn quickly. Takes longer if you review five alternatives and now you have all of their APIs in your head convincing you that they're what you should type instead of the thing you ended up picking.
- Elm takes less than a month to learn extremely well.
- You aren't likely to actually build good abstractions on top of something that makes it hard. Dynamically typed things make it hard.
- I loved Dynamic typing. My email address has "rubyist" in it. I was die-hard that it wasn't a big deal. I was very wrong and wasted a lot of time being bull-headed.
Anecdata
The ~$300K bug
We had a mutable object that represented an important one-off report that could either perform a no-op reporting of the action it was going to take or actually take the action (this was for a pre-paid debit card platform with 400K users). The action in question was "give a bunch of people money on debit cards in a way that we can't perform a takesies-backsies."
It was extremely well tested and survived code review with myself and another senior dev that was no slouch. The ops dev for the night ran it in an entirely reasonable way. But he re-used the object that he'd run the dry-run on to actually execute the action. This was an unanticipated use case.
It added all the disbursements into an array once, to print the report. It proceeded to add them all to the array again, to distribute the money. When used fresh each time, of course, this didn't happen. It never occurred to us that someone would use it that way because its intended use was well-documented. We distributed over $300k more than we were supposed to. People immediately pulled the cash off the cards.
This is the closest I ever came to using my Errors and Omissions insurance. The client was able to recover the money over the following 2 months, but it severely impacted cash flow.
This was ultimately my fault. I was the CTO of the consultancy and should have anticipated this error in my review. Life is better when you don't have to constantly be worried about that class of errors.
The idiot junior dev
(NOTE: I don't think junior devs are idiots in general, by any stretch. But trust me. This guy was stupid. However, the error wasn't his fault.)
We had a service object that accepted a hash (Ruby) and made an API call. Pretty straightforward mapping thing. It had been in production with no issues for a year or so. A new junior dev was hired by the client and pushed, directly to master (we had rules but not systems to avoid this), a fairly innocuous change to it. Unfortunately, he used the passed-in hash (which wasn't frozen because I'm an idiot - this is where it was my fault, but I didn't anticipate the client hiring this kid) as a kind of 'scratch paper' and overrode an attribute that I needed later, introducing an extremely subtle, rarely-induced bug that cost us a ton of money and time (but not $300k+).
Immutability means you don't have to stress about him either!