These are the two biggest reasons R isn't used as a "enterprise" "production" language. Sure, you could rewrite your models in another language, but why would you? That's a lot of developer time. In most cases, it's possible to bolster computing resources. RAM's expensive these days, but developers can be costlier.
There's no rule you must use only a single language for a project. It doesn't always make things easy or performant. It's often best to have one language "in the driver's seat" invoking scripts or programs, giving input and reading output. R isn't going to be an enterprise-running language, but that doesn't mean it has no place in an enterprise.
As for R's poor performance, this is often the "fault" of the code writer. If you want faster calculations, use an array or sparseMatrix. Use basic indexing or assignment instead of filter and mutate.
Most R code is written to be easy to understand and modify. It presents the steps in an analysis like the methodology section of an article. Performance isn't always a concern. So there a lot of R coders who don't know how to write efficient or fast code. But that doesn't mean it's impossible or even difficult. They just need to learn how it's done.
I will agree that some packages are just reinvented wheels. I think of purrr as a repackaging of base higher-order functions with a uniform style for names and arguments. I'm perfectly happy with vapply, mapply, lapply, Reduce, and Negate.