The article is explaining those reasons, which the author feels are obvious but he spells out nonetheless. The gist of his argument is that because UI is not a pure function of a little pile of centrally defined state, React has to come up with lots of new concepts and mechanisms to wallpaper over the conceptual gap. Hence his table which by the end is boiling down to "OOP toolkits don't need this" alongside explanations of very complex FP approaches.
Well, in reading it, those reasons didn't seem to follow on from those points to me. They don't really address working in a pure way from state, just specific things they don't like in a particular implementation.
Specifically "UI is not a pure function of a little pile of centrally defined state" is just this assumption that isn't true, Elm literally gives you no choice, you only have that, and it works, so it clearly can be.
It also ignored all the value you gain from doing it that way. As I say, I've written a fair bit of Elm at this point, and it can often be verbose which can be annoying, but it is actively not complex in the best way, with it being very easy to reason about and bulletproof once it compiles.
