I think you're missing the point.
The main reason it became best-practice to attach scripts at the end of the document is because they block the loading of anything that comes after them until they've been loaded. One of the functions of a script loader is to work around this problem, so scripts can be loaded alongside the document which is beneficial for JS-based apps.
The side-effect is, of course, that with a loader you can't be sure that the document is ready. This is an important enough use-case that loaders such as Require.js provide a DOM-ready plugin to cater for this:
It is possible when using RequireJS to load scripts quickly enough that they complete before the DOM is ready. Any work that tries to interact with the DOM should wait for the DOM to be ready.
The BBC's developer guide explicitly states the need for the document ready method when using jquery in conjunction with Require.js:
You can use jQuery by enabling RequireJS in your application, and using the standard require() method. Require does not wait for the page to finish loading, so you should also use one of the jQuery methods for ensuring the DOM is ready.
You only need to browse through the blogs of a couple of prominent figures in the JS community to see that Require.js is becoming something of a standard for developing JS web apps, so I think it's an important enough use-case to make people aware of.
As a general rule, sure, your advice about putting the scripts before </body> and not needing document ready callbacks is good practice and something I also recommend to people, but I see little point in being dogmatic and asserting that they are never needed.