jQuery popularized the idea of DOM ready (which is DOMContentLoaded to the browser). DOM ready was a big improvement from what we used to do which was waiting for the onload event to fire. It turns out the majority of the stuff we do in JavaScript touches the DOM in some way and you can't read or manipulate the DOM until it's ready. If you have code that doesn't touch the DOM, then sure, you don't have to wait, but those instances are pretty rare in the real world. The big thing to keep in mind is that both CSS and JS block the DOMContentLoaded event. The best thing you can do is keep the CSS and JS that blocks your rendering to a minimum. DOM ready is usually your "perceived performance" so it's best to get there as fast as you can. Instead of trying to get your JavaScript running before on ready, you'd be better off making sure you only have 1 CSS file in your head, that your JavaScript is at the bottom of the page and other standard WPO practices.
>If you have code that doesn't touch the DOM, then sure, you don't have to wait, but those instances are pretty rare in the real world.
Bootstrapping backbone models/collections (or any other kind of data model prep) is the main use-case. A site that is mostly server-driven with some javascript ux wouldn't usually care about this technique.
