If you do end up using RequireJS, using r.js is practically a requirement. Declaring asynchronous dependencies in a production build is murder for performance.
Grunt's grunt-contrib-requirejs[1] does a good job of traversing your dependency graph with r.js and building out a single bundle, but it is not especially quick; it takes about a full 3-5s on my current build. But it's a hell of a lot better than the alternative.
Of course, if I were to start over, I'd run browserify and either build the files in a build step with Grunt or Gulp, or just use browserify-middleware[2] and skip the build step entirely (with something like node-sass for styles).
Well you are right for most front-end application, but what is nice to have is modules, and you don't want almond for that. And by modules I mean you have major pieces of application code that you don't want to load until the user triggers an intent to need that stuff. If you have a single page application and most of your users are just consuming content, why load all the config and editing tool JavaScript? Make modules for pieces of your app, and then if needed load the JavaScript for those things. User clicked edit? Ok now load the JavaScript for that stuff.
Browser caching is nice, but if you're doing a continuous integration/deployment type, you're probably invalidating your cache often. If you use a single build you may be invalidating all of your JavaScript for each tiny deploy even though maybe 1% of your JavaScript changed. Another reason to want modules.
If you're planning on going that route with RequireJS, you should also look into AlmondJS: https://github.com/jrburke/almond