This is just a comeback of a recurring dumb trend based on the fallacy that describing the operations of a program using English words is always superior to using appropriate specialized notation. The core of the fallacy is assuming that because something looks like a familiar English word, people who do not understand programming will understand the corresponding semantics of the operation in the programming language, because they know English. Which is complete nonsense - people who do not understand programming will reason by analogy, and through trial and error end up at a partially wrong and misguided understanding of that operation. English words only start you off with unnecessary baggage in the learning process.
It is even worse for people who already know programming. A C for loop is not a JavaScript for loop is not a Python for loop... The details of their semantics are very different, and you will introduce bugs if you just assume "I know how for loops work!"
There is nothing new about this trend either; it was the central premise behind COBOL, and a big motivation for BASIC. What BASIC was in the 1980s, Python is today.
What is ironic about this trend resurfacing today is that it has never been easier to use special characters - Unicode is everywhere, and even making custom keyboards has turned from a major manufacturing endeavor to an accessible hobby: https://www.youtube.com/watch?v=uk3A41U0iO4
That being said I agree that these days the tendency across all languages is to go towards fewer special characters, not more. In this context Perl 6's syntax feels a bit anachronistic.
Maybe you'll be able to win a few new user by telling them that in Perl 6 they can use × for *, Ⅻ for 12 and [unicode atom symbol]++ (ironically HN automatically removes the actual symbol when I submit) for atomic incrementation but I expect that many more will recoil in horror. I won't even talk about »=» and the ascii equivalent >>[=]>>.