It's a little easier to have foobar.update(), rather than update(foobar, state).
I started off mostly programming in R, so using mostly bare functions, but I have to admit that objects are really, really useful when you need to maintain state. Yes, you can do it with closures, but it's a little harder and a little uglier.
That being said, the mutability that makes objects useful is also problematic in that you can end up with magically updating references without defensive copying.
I don't know R and I don't really want to know it. For me, it doesn't seem to bring anything extra to the table that I couldn't do in Clojure or ClojureScript much more consistently and simply. If in my project, I have a number of transformation functions for my state, passing it around isn't a huge deal as it is just a nested map usually. It forces you to be very consistent and helps you as the project grows. Also, most of the functions are easily transferable between projects even when the state would have a very different structure.
Of course the whole thing is a complicated topic and in some cases you want mutability and local state e.g. because the performance is a bit better. Usually, that involves a few simple transformations.
And if you figure out how to fit a generalised additive model in clojure with one line of code, please let me know :)
So, in DS/stats you end up needing mutability because the datasets are really large, and the models take a long time to run, so copying is generally bad.
I see nothing wrong with OOP. It is convenient for many things. It is not a silver bullet though. Nothing is. Personally I do not adhere to any concept / programming paradigm. They're just tools. I use many. Depends on what I am doing.
Generally one can take a tool and put it to good use while the other will fuck things up regardless.