A couple of years ago we had a student who wanted to call CPLEX from R and I think after spending a lot of time with a colleague they couldn't get it to work. The situation may have been improved, but back then Gurobi was a lot easier to call from R, and these kinds of struggles may be one reason why R is not very popular in papers that focus on MIPs. There are also not many tools available in R that can help you use commercial solvers in a convenient way. In one of our postgraduate courses we actually developed a small R-script that makes it a lot easier to manage variables and constraints on top of the standard Gurobi API. Python has packages that make those kinds of things easier, and with CPLEX you can use Concert technology in most supported languages that makes those kinds of things a lot easier as well. The lack of such technologies may be a second reason why R is not so popular for MIP papers, although this is a situation that may get better and better as time passes.
Furthermore, as you mentioned, for iterative computations the standard GNU R interpreter is really slow. There are some efforts to create faster alternative implementations of the R language, mostly based on Java technology, such as the experimental FastR interpreter by Oracle. The language itself was designed for statistics and I think ease of use for statistical usage is a much more important goal of the language than efficiency of arbitrary algorithms written in it.
If the speed of your math heuristic is a concern, in particular if it must make as many iterations as possible, R's speed is something to consider. Many core parts and popular packages of R are contain parts writte in C or Fortran to keep stuff under the hood efficient. If your heuristic is not really about iterations, i.e. you do a single preprocessing step, solve a MIP once, then do a postprocessing step, it is only important whether R is "fast enough". If the pre and postprocessing take 10 seconds in R, no one will complain that you can do it in 0.1 seconds in some other language (unless you want to run this heuristic millions of times).
So it really depends on the story you want to tell with your paper: if you solve a problem from practice and intend to investigate how you can improve some process with optimization techniques, it is usually enough to show you can solve it fast enough to be useful and focus on the objective values that come out. If you want to argue that your new method is faster than the state of the art for a problem that has seen a lot of research already, it becomes a greater concern.
Also, be aware that no one forces you write all code of a project in a single language. Personally I like to do most computational expensive stuff in Java, but I often use Python scripts to do some data transformations or stuff that other people probably like to do in Excel. For some types of visualization and statistical analysis I sometimes use R as well, if that is more convenient than Python.
If the main reason you like R is the built-in dataframe but R's speed is an issue, you can look at dataframe packages for other languages. Python has the extremely popular pandas package and for Java there are also packages that aim to provide a more easy to use data frame, for example Tablesaw (but I'm not sure how popular that one actually is).
While data frames are nice to process tabular data, I really dislike dealing with more complex hierarchical object data in R. Navigating an XML-tree or accessing particular document elements of an HTML page in R always feels cumbersome to me compared to other languages. The ease of data processing in R thus also depends on the kind of data processing you intend to do.