Hey @forgottenpass, perhaps I can shed some light. Please keep in mind these are my personal thoughts, not Codeanywhere's.
Building an IDE is a really, really, _really_ complex thing to do, and building one on the Cloud is 10X harder because the toolchains are much more complicated, and the technology is sometimes not even there and you have to break through technological barriers. It's telling that the other Cloud IDEs had millions of funding, and some of them still failed.
So the very first upside is that you can combine forces. 90% of the work is generic, and it's currently being done twice for 2 different Cloud IDEs. There's no point in reinventing the wheel. Add to that the Marketing costs that are also double, etc etc, and you can start to see how, organically, joining forces is better for both. Add to that the shared visions both companies had and the complimentary solutions/markets (one for Web Devs, one for Makers), and you start to see some big wins for all.
People naturally overvalue physical goods and their cost to make, while under-valuing virtual goods (you're willing to pay for a $10 coffee with a 95% profit margin than a $5 Monthly subscription)
In the Maker movement, people gladly buy an Arduino with a 75% markup (the final cost is 3-4X the cost of making it), but they wouldn't pay for an IDE, or a library etc.
It's also true that there are many things aiming for your hard-earned money so people are reluctant to go ahead.
And then of course, there's the competition. With the Arduino IDE (and now Arduino Create) being available for free given Arduino's business model (make money from H/W), Makers aren't incentivized to pay, in fact they (naturally?) expect other things to be free as well
In regards to the Yun, we don't support it yet, essentially because we don't support the Programming-over-Wifi. But anecdotal evidence from other companies we've spoken to seems to show a single-digit usage (usage, not sales).
As for new boards... that's also a very interesting question. It does fluctuate, but not as much as you'd think. The case that stuck out most was actually the case of the Arduino Nano clones with the CH340G chip, which made Nano the 2nd most used board.
New boards tend to have a spike in "apparent interest", if I may call it that, in other words in things like Page Views on pages that have to do with the board, or Newsletter clicks, etc, but the actual usage is more gradual
For the moment, we only use it for syntax analysis and to give a beautiful error output for our users. There is an active LLVM backend for AVR with great ponential, currently under development and from what i understand, Atmel is backing it as well, but it's not stable yet. We would like to try it out though.
P.S. A size comparison will be very interesting. I will go out on a limb and assume that LLVM spits larger binaries when optimizing the code for speed. We use -Os to optimize for size, so it will be interesting to see which does the best job.
simonbarker87 makes a great case for us on the comments below. i'd just like to add that it generally skips the (sometimes painful) process of installing and updating the hardware. everyone who has taught a workshop or class on Arduino and had to help about 10 people get set up probably knows what i'm talking about.
marssaxman i'd be very sincerely grateful if you'd like pre-register and test it. the thing that got us started in the first place was the limitations of the Arduino IDE, and we think we did a great job with that. we really do have a much better editor, as hackaday elegantly put it, "codebender uses clang a wonderful compiler that will give you extremely descriptive warnings on terrible code." plus a better way to manage your sketches (instead of relying in a directory with 100s of projects).
anyway, in regards to your question, if you've ever used a big project (20-30k when compiled), it can take quite a while to compile and less time flashing. plus, the Arduino IDE compiles it every_single_time although there is no need to, so if, for example, you want to flash this code to a nub you're spending more than half of your time recompiling the same code for no particular reason
It wasn't that hard, really. Originally we wanted to use Firefox's and Chrome's native javascript APIs, but they aren't stable yet, we had to do double the work and even then we could only target two of the major browsers. So what we do is run a Java Applet which communicates with our Javascript and gives us access to the serial ports.