Not to belabor the point on syntax too much, but it's my opinion that such changes are minimally substantive. I mean that, they are of equal value to the keyword changes, which might make the overall reading-of-code-out-loud easier, but do not do anything towards making the actual code constructs easier to understand.

Their efforts seem to have been fundamentally focused on making beginner-level Java-style program code easier to understand when read out loud. That's a fine start. But it's still very low-level. List comprehensions, unified numeric stack, pattern matching, functional stream processing, etc., the general idea of making code composition easier, has not been addressed.

This is also a problem with FP, though. FP circles dress up these concepts in difficult-to-understand mathematical language and wallow in it as a badge of honor. I'm sure we're all familiar now with what has become a joke-line "a monad is a monoid in the category of endofunctors". Monads in usage are actually quite simple, and we can start to use them effectively without ever knowing that they are even called Monads. So a lot of work needs to be done from that direction, as well.

In other words, calculus might be difficult to learn, but it's easier than using arithmetic to understand change of functions. You don't make your programming language easier by limiting the constructs it has available. You make it easier by expanding them, so that the more difficult concepts are easier to lift, don't require as much low-level reimplementation without them.