For me its not the code/language that is un-intelligable (all code would require me to stop and try to brain interpret it); but the fact that the article at least to me refers to too many things at once. Talking about dependency handling, using data structures with dispatch vs direct function calls, data types for errors vs exceptions, expressions, etc makes the article dense to read and hard to skim.
Many programmers have used these techniques even outside FP and would be able to understand it one concept at a time - they aren't advanced concepts to me. It's more that it isn't "easy reading"; but it seems its for an internal audience with assumed background knowledge.
The author said in a comment here that it was written for an FP audience.
The example you gave is similar to a discriminated union in ML but it is not as robust because the language will not check that every match expression (probably an if-instanceof-ladder in Java) handles every case.
The only way to make it the norm is to make it the norm.
Maybe someone sees this...
...instead of this... ... and thinks "I should look into this more".That said, I don't want to put words into the author's mouth, but this particular article looks more "by FPers for FPers" than FP advocacy.