R was developed for and by statisticians, for better and worse. I used R a little bit 15-20 years ago, what I remember was that quite a few libraries and function interfaces seemed to be designed to be convenient for interactive use, but if you tried to use them in an automated script, e.g. some analysis you wanted to scale up and repeat 10,000 times while bootstrap sampling or hyperparameter sweeping or what have you, those same library and interface design choices involved bizarre edge cases where functions would sometimes do something completely different (perhaps changing the return type) when invoked with slightly different arguments. All these automation hostile edge causes were annoying to discover and then work around.

None of this was forced by R the language, it was purely a library design thing by the folks writing the libraries. Whereas in contrast, you simply wouldn't and didn't get such library design in mainstream general purpose programming languages (e.g. in C++, java some of this stuff wouldn't even type check) and similarly in python, even though python being dynamic was fertile ground for people to develop completely bonkers and unautomatable numeric and scientific libraries, the customs for how libraries should work were different

This is maybe just a reflection that R and R's libraries were being designed for interactive use by humans doing exploratory data analysis, model fitting etc, unlike other programming languages which are used to automate things or build software products that can be shipped.

I think what people miss about R is that if you go on with an object oriented for loop way of writing code like a lot of python devs tend to do, you are going to have a bad time. You write functional code and make use of various apply functions instead of loops, it’s going to be very performant. A lot of it is wrapping C.