It's not that I don't understand there were reasons for choosing the names. I just think they were confusing reasons. :)
It reminds me of Haskell, where monad is such a terrible name. Same with functor, applicative functor, etc. Yes, all these names aptly and mathematically describe what they do, but the most precise name will not help beginners understand.
For instance, if reducers were called "state updaters", I think people would be less confused. Same if "map state to props" was called "get props from state".
Sometimes you gotta give up on giving the most precise name and instead give a name that is the most clear for the greatest number of people.
FWIW, I agree with you--I feel like there's a distinct "pull the ladder up behind you" notion in the land of bleeding-edge software (not just FP, but I'm lookin' that way), where a vocal and influential chunk of the community has decided (and enough others have followed along) that a certain kind of exclusive specificity and conscious choice of high-level vocabulary matters more than the other people who might benefit from the stuff. And then inertia means things don't get better.
Many programmers are bad at naming things. Many are bad at doc. None of this stuff is actually hard, it's just made hard and made unfriendly in unfortunate ways.
"Reducers" come from the similarity with the callbacks passed to `Array.reduce()`, "thunk" is an existing CS/programming term, and "saga" was also adopted from the backend world. So sure, a lot of these terms are new to most people (especially front-end developers), but they were generally based on existing terminology and not just picked out randomly.