I think the person you are responding to is simply saying some things are more complex than others and require more understanding and experience. R apparently falls into that category. If the author wants to gain that experience, I think the time spent on this blog post may be better used to reading a book on R. Fault might be a strong word, but the author has certainly made a decision on what they spend their time on and the results are as expected.
some things require more understanding and experience, for no obvious benefit...in which case they're anti-patterns, or not best practice in language design.
there are a lot of things in R that are good but it's an old language and there's a lot of cruft.
and believe it or not, there are things that require looping through a data frame and when I had to do that a few years ago it was unbelievably slow... going multithreaded was non-trivial, writing that section in C was non-trivial...ended up rewriting the whole thing in python and was a lot happier.
data frame has 2 columns, 20 years of portfolio returns, and 20 years of % withdrawn.
using a starting portfolio value, calculate the 20 ending portfolio values for each year and the dollar amount withdrawn.
worked ok looping through the data frame, but was unreasonably slow.
never figured out how to use a vectorized method that could go through the frame building each new element from the one previously calculated.
maybe I missed something obvious?
(the parallel part came in because I was doing it on a lot of portfolios, so to speed it up just launched the same slow function on several lists of them in parallel. writing that one function above in C probably would have been OK. I think I got it to work but then I couldn't get the right version of compiler to work with the right version of R which supported the other libraries I was using. was a few years ago so maybe things weren't as stable. I never said I was very good :)
