When I was teaching graduate level statistics, I was telling my students: "I don't care what package you use, and you can use anything for your homework, as I expect you to provide substantive explanations, and will take points off if I see tr23y5m variable names in your submissions. I can support your learning very well in Stata, and reasonably well, in R. With SAS, you are on your own, as you claim you have taken a course in it. With SPSS or Minitab, God bless you". I imagine that the reasonable employers would think the same. What matters is your productivity in terms of the project outcomes. If you can achieve the goal in R with 40 hours of work, fine; if you can achieve it in C++ in 40 hours of work, fine; if you know how to do this in R in 40 hours, but your supervisor wants you to do this in SAS, and you have to spend 60 hours just to learn some basics and where the semicolons go, that can only be wise in the context of the large picture of the rest of the code being in SAS... and then the manager was not very wise in having hired an R programmer.
From this perspective of the total cost, "free" R is a hugely overblown myth. Any serious project requires custom code, if just for the data input and formatting the output, and that's a non-zero cost of professional time. If this data input and formatting requires 10 hours of SAS code and 20 hours of R code, R is a more expensive software at the margin, as an economist would say, i.e., in terms of the additional cost to produce a given piece of functionality. If a big project requires 200 hours of R programmer's time and 100 hours of Stata programmer's time to provide identical functionality, Stata is cheaper overall, even accounting for the ~$1K license that you need to buy. It would be interesting to see such direct comparisons; I was involved in re-writing a huge mess of 2Mb of SPSS code that was said to have been accumulated over about 10 person-years into ~150K of Stata code that ran about as fast, may be a tad faster; that was about 1 person-year project. I don't know if this 10:1 efficiency ratio is typical for SPSS:Stata comparisons, but I won't be surprised if it were. For me, working with R is always a large expense because of the search costs: I have to determine which of the five packages with similar names does what I need to do, and gauge whether it does it reliably enough for me to use it in my work. It often means that it is cheaper for me to write my own Stata code in less time that I would be spending figuring out how to make R work in a given task. It should be understood that this is my personal idiosyncrasy; most people on this site are better useRs than I am.
Funny that your prof would prefer Stata or GAUSS over R because "R was not written by economists". Neither were Stata or GAUSS; they are written by computer scientists using computer scientists' tools. If your prof gets ideas about programming from CodeAcademy.com, that's better than nothing, but professional grade software development is as different from typing in CodeAcademy.com text box as driving a freight truck is different from biking. (Stata was started by a labor econometrician converted computer scientist though, but he has not been doing this labor econometrics thing for about 25 years by now.)
Update: As AndyW commented below, you can write terrible code in any language. The question of cost then becomes, which language is easier to debug. To me this looks like a combination of how accurate and informative the output is, and how easy and transparent the syntax itself is, and I don't have a good answer for that, of course. For instance, Python enforces code indenting, which is a good idea. Stata and R code can be folded over the brackets, and that's not going to work with SAS. Use of subroutines is a two-edged sword: the use of *apply() with ad-hoc functions in R is obviously very efficient, but harder to debug. By a similar token, Stata locals can mask nearly anything, and defaulting to an empty string, while useful, may also lead to difficult-to-catch errors.
