R vs SAS, why is SAS preferred by private companies? I learned R but it seems that companies are much more interested in SAS experience. What are the advantages of SAS over R? 
 A: Customer support.
I once had a chat with a friend working in a company specializing in installing servers, and he then explained to me why big companies always opt for Microsoft products rather than go open source. The advantage Microsoft has over its open source competitors is the customer support. If something goes wrong with the product, the company can call Microsoft, big companies even have personalized support for them. Not so with open source software.
I think that is the exact same reason SAS is getting precedence over R.
A: I once worked for a consulting company that gave SAS assistance to a large chip manufacturer in the Silicon Valley.  Our contact person at the company told us that he got an offer by another company to give them the exact same consulting, by using a different software which covers all areas covered by SAS and which would cost the company a fraction of what SAS was charging them (\$30,000 as opposed to \$1,000,000).
The contact person considered what to do and decided against informing his boss about the offer because he feared getting fired for using SAS in the first place and not considering cheaper alternatives.  Instead, he insisted that our consulting company give their company a big break in our consulting fee.  Our company agreed.
A: What about Frontends? What is R's equivalent for the SAS Enterprise Guide, Web Report Studio or Enterprise Miner?
Edit:
These tools make it possible for a non-programming User to use a DATA WAREHOUSE, without knowledge about the underlying technology. They are not primarily tools for the use of SAS as such.
R GUI's are just IDE's for the R language/system, AFAIK. They cannot provide help for the non-technical user who wants to gain information & insight from the DWH.
A: On top of what gung has correctly identified here, the biggest issue in the corporate world is legacy. And when you have a good quality production code that is known to do the job, you don't change it. SAS was out there since 1970s, and at the time it was the only effective, by then-standards, scripting statistical language. The amount of production code accumulated since then in SAS in pharma and government is unimaginable, tens of thosands of human years. Rewriting this in R or Stata would take a few years, the resulting code will become more flexible, more efficient, more transparent, easier and cheaper to maintain, but nobody will pay for such refactoring. (My experience doing this is that my Stata code is generally about three times shorter; I once had a project converting SPSS code into Stata where I made it about 20 times shorter. For those of you who worked in maintaining your statistical packages... well, you know what that means.)
In a sense, this is a similar story with the academic publishers: they are riding a tide of the end users maintaining their subscriptions out of necessity; a university without subscription to Nature is not really a university. Free publishing via professional societies will make it cheaper, people prepare their submissions in LaTeX these days, so they are camera ready, and the same people will be providing the peer review, so there will be no quality setback on any of the dimensions. But... there's no brand name and the impact factor behind the online journals.
This sums it all up: http://scatter.wordpress.com/2011/06/28/stata-12/. Stata is preferred in economics and policy-related circles, and the more I learn SAS, the more I like Stata.
A: I don't think application security has been mentioned. This question was raised in Stack Overflow but dropped since it was off topic.
I collaborate with the the Swedish National Board of Health and Welfare that use SAS. When I talked to their statisticians (that like R) they claim that their IT-folks prefer SAS since they don't trust the packages downloaded in R. My wife also works in SAS and her institution often claims the same issue...
I would love to see some comments on this issue. I've done a quick search but haven't found any good references...
A: The reason I understood to be the most convincing was that SAS has an extensive library of vertical business specific modules that people in these verticals all use, so it is somewhat of a lock-in.
But also that SAS has addressed the needs of these vertical segments in business and optimized around their needs - optimized in the sense of "user doesn't have to do a lot of extra work to get the results".  I am not a SAS user, so this is not meant as a biased defense of the SAS business strategy. 
A: I have worked as effectively a SAS programmer for the last seven years, next to me a co-worker has been programming SAS longer than I have been alive.  As noted here, there is a massive amount of inertia/legacy behind SAS; but SAS just like R is a way to a means, not the means itself.  
SAS is extremely efficient at sequential data access, and database access through SQL is extremely well integrated.  PROC's are very well documented, but unfortunately not-entirely standardized with notation (PROC OPTMODEL and IML are two examples).   It is a bit clumsy when it comes to writing complicated code, and not as elegant for parallel code.  I have also found importing csv files to be a source of great misery at times and prefer to just dump it to R first then to a database.
Although SAS does have interfaces to shared objects and dll's you don't get nice access to any header files or anything like that, and code distribution also isn't available through happy packages.
There is however little concern about someone including some esoteric now-defunct or broken package in your code that you now need to maintain, and the quality of the code in SAS tends to be uniformly excellent (R core code is also excellent, and also freely available to anyone).
As mentioned before SAS is also extremely expensive, but it is a good tool that I go to when I know there is a canned procedure that works well for my needs.
R + SAS + mysql with a little bit of perl to glue to them together works amazingly :)
A: So I use both R and SAS - admittedly in academia - but there are a couple reasons that I tend to head toward SAS at times:


*

*Better documentation. R is getting better at this, but documentation, especially the official documentation, is often kind of terrible and opaque. Beyond that, SAS is supported by a massive infrastructure of books - the use R! series is helping this in R, but it's not quite there yet. I can turn to Paul Allison's Survival Analysis Using SAS, or Categorical Data Analysis Using SAS or the book I have on Monte Carlo methods using SAS and I have a book clearly written in a fairly consistent style for the language I'm using.

*Inertia. This isn't just "companies are lazy" - inertia has value too. There's institutional knowledge. So-and-so has code that does that - and does it well.

*Packages. Some packages in R are amazing. Some packages are not. You have to go find them, evaluate them, and even then there's some leap-of-faith issues in that the package is only as good as the guy writing it. It's hard to trust that. SAS has essentially the "full faith and credit of the SAS Institute" which has a pretty solid track record.

*Single-source support. If SAS is broken, you call SAS. If R is broken you call....?

A: Nobody has suggested the reason it is preferred is plain idiocy. Here's two quotes I recently came across:

"Using open-source software such as R was out of the question – we
  couldn't guarantee a perfectly repeatable outcome"

and

"We would be unable to provide any support for this as it is open
  source software"

Two minutes with these people would show them how wrong they are. 
A: Being the big commercial product that SAS is, there's a strong and coordinated effort by payed salespersons to promote it. I don't think that efforts to promote the usage of R can match these.
A: I look at Open Source or licenced software like this, be it SAS or anything else. My IT department is there to provide a service to our business. The company earns no money from IT, only from the business IT supports. The business has annual revenues of \$16 Billion. IT costs around \$200 million a year. If money was the issue I would cut costs, but if I save 10% (\$20 million) of my budget, will the business notice? Will they just reduce my budget next year? If the IT fails the business loses revenue, how much will vary on the nature of the failure. Parts of the business may no longer earn revenue. If a product like SAS fails, I can sue under a contract. If an OSS product fails, I cannot. I will not recover my \$16 Billion, but I may get some back, and realistically with SAS, you are unlikely to lose the lot. The difference in price versus cost has to justify any additional perceived risk to the business. Sometimes it is cheaper to stick with SAS than to retrain. Sometimes there are higher priority issues, so companies stay with SAS. Some companies do not need the full functionality in which case alternatives are viable. Some do not need the support and again the alternatives are viable. If you meet the business requirements then either options are valid, if you want to provide support for a business you need to look at the total cost of ownership over 5-10 years, the ability to recruit experts in the tools, stability in the product so you don't have to rewrite everything with each new release, the training courses available to skill up, the size of the potential skills available in your region... Often the biggest problems with OSS come about through the poor architecture of the products, look at Linux when 64 bit processors came out, look today at MySQL was recently ported but without support for secondary indexes which is coming later...
A: One issue does not seem to have been addressed explicitly: ass-covering. If you go with SAS and things blow up, the decision maker can always say that he bought state-of-the-art software, and how was he to know it would break? If he decided to go with R, this argument will be harder to make. Yes, this is related to the inertia argument already mentioned here.
A few decades ago, they used to say that "noboby ever got fired for buying IBM", which has been called the greatest marketing phrase ever.
A: The times they are a changing
As of 2015, actuaries under the age of about 35 prefer using R - the text books use both R and SAS code.  Older actuaries never learnt to use R and prefer SAS and do not use R.  The proportion of actuaries actually coding in SAS will decline.
If you search Google scholar for papers referring to SAS - then you will find a steady 550-ish publications per year for the last few years.  If you search for papers using R ("R Foundation for Statistical Computing"), there were 25,100 in 2014 and as of mid-July 2015 there are 16,700.  Plotting the rate - it's growing very fast!
SAS didn't help themselves for a few years by demanding large licence fees from universities - which they have since reversed - but it is now too late many universities have converted to teaching using R and not SAS.
New statistical techniques are published in papers in conjunction with an R package.  Some techniques that have been in base R for years have still not appeared in SAS.  You can now use R from inside SAS.
In summary, things are changing and changing fast.
A: As a user of both SAS and R, I would say the biggest reason we use SAS over R (when we do) is its ability for sequential processing.  We only need machines with no more than 4GB RAM to process 15 years worth of data.  I would need a much larger machine using stock R and I have not tried to migrate the SAS code to run with Revolution R.  
A: In the pharmaceutical industry SAS is used because it is what the FDA uses and likes.  There are some serious reasons though. Results are traceable and the output has a time stamp.  FDA statisticians can check what you get.  It is very good for database management and it is reliable software.  Of course many of the attributes of SAS can be argued to be present in other software packages including R and SAS is expensive.  Still I think anyone wanting to be an applied statistician working in industry will be best off to at least learn how to program in SAS.  Use R or STATA if you prefer but know SAS.  When you work for a company that wants you to use SAS they will pay for the licensing.
A: I think this quote from Anne H. Milley sums up the way a lot of people feel about R:

We have customers who build engines for aircraft. I am happy they are
  not using freeware when I get on a jet.

Unfortunately, I think this misconception (free==inferior) is common in the general public.
A: Some reasons that I haven't seen mentioned:


*

*Better documentation.  SAS documentation is verbose, R documentation is terse. Many companies may prefer verbose documentation.

*Better error messages. R's error messages often seem designed to prove that the person writing the message is smarter than the person reading it.

*Tech support. SAS has some of the best tech support I've run into anywhere, provided by SAS. You can get help with R, but that help is scattered over different places and isn't always available. The people on the various sites that provide help with R are volunteers - and volunteers aren't obligated to help.  The people at SAS tech support are paid to do what they do - and they do it well. Not only do they do it well, they do it politely a trait that is often not present in all R communities (my favorite? "I got help by typing 'help', why don't you try typing 'help'?")

*Ease of coordination with Word and Excel. Yes, I know you can get R to do this, but it's easier with SAS (on the other hand, R works better with $\LaTeX$ but a lot more  companies use Word). 
A: I think the legacy angle can be a big one for the following reason. An organisation hires a person, call them person X. They are a computing guru/wizard/etc. They build awesome SAS programs/tools/etc. They are so good that other people in the organisation don't feel like they need to understand how the programs work. They make it so easy to just push a button, and everything just works (the magic black boxes).
Person X leaves the organisation. Unfortunately, the knowledge that person X has leaves the organisation (documentation and knowledge management was not prioritised, working programs was instead).
They are replaced by person Y. Person Y is great with R but has no idea about SAS, and hence has no idea about how the SAS programs actually work. There is a huge learning curve to even figure out what needs to be translated into R.
For example, person Y can not tell if a data transformation has been done to enable a proc to be called, or for merging with other data, etc.
The transformations needed are probably different in R, because the functions are different, and the defaults are different (e.g. treatment of categorical variables in proc glm vs the lm())
So, you are now faced with a unequal cost trade off. Say the cost of re-writing / translating from SAS to R is $C_T$. We then need the (small?) efficiency gain from moving to R (I say small based on my experience with optimising SAS code and optimising R code for logistic regression predictions). This also needs to be compared to the license costs for SAS. It is likely that $C_T$ is significantly higher than a single year license for SAS. I expect that SAS would be doing some analysis of this trade off, and letting this influence how it sets the licence fee (well, I would if I worked at SAS).
Also notice how SAS plotting procedures are way better than a decade or so ago (eg proc sgplot vs proc plot). coincidence that R did good plotting first? I think not! This effectively reduces the efficiency from switching because plotting is not so different anymore - R is still better, but not by enough to switch...
A: (slightly off topic): viewing it the other point round: some of the advantages R has in academia don't apply to industry. 
E.g. in academia it is a clear advantage if you can tell the students to go and get the software and work at home. In industry, you're usually not supposed to take any data home with you...
Neither are you supposed to try out a few things(TM), download tons of packages (even if reputable & tested), use cutting-edge methods. Instead you're usually expected to stick to methods & code that have been used for years and where the behaviour is known for ages. 
You wouldn't win much academic merits with that.
And of course, as has been mentioned: noone is going to risk redoing all kinds of regulatory approval for the sake of switching to R. From what I've seen that's less about R and more about the enormous costs + work for getting regulatory approval.
A: I think there are several issues (in ascending order of possible validity):  


*

*Tradition / habit: people are used to SAS, and don't want to have to learn something new.  (Making it more difficult, the way you think in SAS and R is different.)  This can apply to anyone who might have to send you code, or read / use your code, including managers and colleagues.  

*Distrust of freeware: I've had several people say they aren't willing to accept results from R because you don't have a for-profit company vetting the code to ensure it gives correct results before it goes out to customers, lest they end up losing business.  

*Big data: R performs operations with everything in memory, whereas SAS doesn't necessarily.  Thus, if your data approaches the limits of your memory, there will be problems.  


Personally, I only think #3 has any legitimate merit, although there are approaches to big data that have been developed with R.  The issues with #1 speak for themselves. I think #2 ignores several facts: there is some vetting that goes on with R, many of the main packages are written by some of the biggest names in statistics, and there have been studies that compare the accuracy of different statistical software & R has certainly been competitive. 
A: Whilst its quite pessimistic, my answer would be that the kind of people who make sweeping decisions in corporations like 'we just use SAS' are also the kind of people who don't trust what they don't understand, and automatically think the value of something is directly proportional to the amount of money you spend on it.  This leads them to prefer paying for SAS rather than spend time investigating alternatives.
A: Why would a major drug company even want to convert to R from SAS? SAS costs millions but it is nothing to a drug company. However, converting all the stable reporting systems from SAS to R would cost 50-100 times more. 
SAS has phenomenal support system: every time I needed help they were able to provide it within few hours.
And what exactly does R have that SAS does not:
1) better graphics...ok, it is a big one but graphics are not everything. besides R can     always be used an extra tool to create some cool graphs and SAS is not too bad when it comes to graphics
2) modern and more efficient programming language. Many SAS users are not programmers and don't care about using a cool language. They just want to be able to analyze the data.
I love R but it would be insane for a big company to convert to SAS. It could make sense for smaller firms though
A: There are several main advantages, in no particular order


*

*SAS has a large installed base and a long track record


I'm purposefully avoiding use of pejorative terms like "legacy" or "habit"  Many companies have been using SAS for 30 or 40 years, and they have millions of lines of working code. In addition, there are all of the benefits of a stable code base with millions of user days in an area where small errors can be critical.   This is the same reason that Unix flavors are still popular even though Unix is over 40 years old and obsolete in some ways.  Finally, there is a large community of experienced SAS professionals who are used to solving business problems


*

*SAS is well suited to heterogeneous, complex data and operating environments


Companies have lots of different data sources, based in different types of systems, as well as in many cases, multiple operating environments.  R has only very recently gotten some extremely basic capabilities to deal with more than can be kept in memory.  Compare this with SAS's ability to support native, optimized, in-database processing for terradata, to cite just one example.  In most real world situations, the hardest part of analytics is dealing with the data and operating environment. (need to run your Windows developed model scoring code on the mainframe?  With SAS, no problem.  With R, you are out of luck.)  R doesn't solve any of those problems. 


*

*The user doesn't have to worry about being "on their own"


A SAS user can be reasonably certain that every code module has been tested by qualified people. It is not necessary to devote time and effort to learning the provenance of the code, or independently validating it.  Furthermore, if issues of any kind are encountered, robust assistance (from something as basic as documentation to something as comprehensive as detailed exploring unexpected results or behavior of a sophisticated method) the user can pick up the phone and get help.  


*

*It's "good enough"


The language turns off some people because it is different than modern languages for general programming.  Having said that, the language is high level, powerful, expressive, and comprehensive.   In short, once you learn it, it gets the job done.   For companies, the elegance of the solution isn't much of a selling point. 
A: In addition to the good answers so far, I'd add the embarrassment factor. If you spend hundreds of thousands of dollars last year on SAS and SAS support, and you propose spending nothing for R, with extremely low support prices (Revolution, etc), someone up the chain's going to ask why. Was it a mistake to spend so much money last year when R existed last year? Or is it a mistake to drop professional software for something created by a group of volunteers?
Once the problem's framed in that manner, it's a lose-lose proposition, so perhaps better to not bring it up.
A: For industrial statistics, there are quality assurance people who (usually) have no programming, statistics, or science background and who audit statisticians, programmers, and scientists. They want to know, "How do you know that what you're doing is right?" and "If it's wrong, how can we blame somebody and how will they pay for it?".
The GNU/GPL Copyleft license comes with canned text that says, "R is free software and COMES WITH ABSOLUTELY NO WARRANTY" in all-caps text exactly as I have written. This is offputting. When a quality person reads this text, they basically discredit R outright. I mean, if a product is good, it's worth adding a warranty right? Such has commercial products led us to believe. In fact, it was ultimately the FDA who said they would accept regulatory submissions in R that reflected a seachange in the software industry. (Note this statement comes after the original posting date of the question.)
For someone who knows nothing about computers, the imagined scenarios of security, irreproducibility, and grave scientific errors are unbounded as a result of this ABSOLUTELY LACK OF WARRANTY.
 We all agree mistakes can have catastrophic costs. For your SAS license, SAS has experts who can explain their software to auditors, and in the impossible scenario that SAS actually causes such an issue, they can be accountable for fines and punishments (they also have enough money for lawyers to ensure they'd be exonerated completely in such a case). The burden and cost of having an analyst/programmer present this case for R basically amounts to a SAS license. Not that programming in SAS completely exonerates you from the crushing burden of quality compliance!
So basically, I would say litigiousness has played a prominent role in necessitating a costly license software. 
