We have a mostly per-project set of code style and tooling guidelines. Most (if not all) of our larger projects are coffeescript and commonjs based. That's mostly because they all share at least some code. As long as a project is internally consistent and the team agrees with each other, we don't force any specific styles or tools (within reason). We have expertise with the tools we use the most though, so a lot of times the best fit is our own tools.
However, the comparison is a little bit apples and oranges. The JavaScript is optimized for reading, and maximum coherence by outside developers (an example), and the other is a compiled application for execution. The actual _source_ of the checkout project (which is not open-sourced) internally is broken up into neat files and uses modules, etc. It's quite readable for those working on the code, and the output there is generated by a computer and not really intended for humans.
Hope that helps give some insight into our process and reasoning.
* People don't compile to JS before publishing to NPM, making it harder to use CoffeeScript written modules.
* I don't know CoffeeScript, so it's harder to debug.
* The language is bad, introduces things from Ruby he doesn't like, there are ambiguities introduced.
When asked about ambiguities introduced, there was a reference to a "different require implementation in CoffeeScript", which has possibly since been fixed.
to something like https://checkout.stripe.com/v2/checkout.js is like night and day. JS vs. compiled CoffeeScript. One large, monolithic file vs. obviously concatenated files. Variable naming, commenting, etc.
It's interesting -- I wonder what kind of code style guidelines they have over there, if any.