Earlier quoted context omitted.
My guess would be leveraging all the libraries and packages in R, without having to rewrite them in D.
Here's what I'm not getting: Most the tasks that require heavy computation in R are done through C/C++/Fortran APIs - why can't D interface with them without the intermediate R layer? The ones that are R-native - visualisation/dataframes - are best done through R itself - what's the use case for doing that through D at all?
1) Use a library written in raw R that is difficult to implement in another language. It can be time-consuming to replace the work done in raw R.
2) Use a library that relies on a C/C++/Fortran API, but then provides additional error checking or providing additional calculations using raw R on top of it. It can be time-consuming to replace the work done in raw R.
3) Use a library where the R implementation has an ecosystem built around it. It can be time-consuming to replace the R ecosystem.
4) One way that I used this in the past was with Stan. Stan is written in C++, but they do not provide a C++ API and you either call it at the command line with cmdstan or use an interface like rstan or pystan. The problem with calling it at the command line is that you have to write the data to a hard disk first. You don't have to do that with rstan. My recollection was that it was faster to call rstan from D than using cmdstan for large data sets. So basically, I can process all the data in D, which tends to be faster than R or Python, and then pass it off to Stan.
5) When attempting to produce a D library with similar features as an R package, one can create a unit test that calls the R version and check that they provide the same results.