For single-page apps, the advantages are pretty clear … having explicit, structured dependency declarations and using an async script loader seems like the way to go.

Those aren’t the only advantages, though. AMD-style modules don’t just remove the need for namespaces, they provide other benefits, like eliminating hard-coded dependencies and facilitating dependency injection for mocking/testing. This question goes into more detail.

However for a more traditional, multi-page design … you’d just put those all together into a single script on the server side and download it in one go – loading separate modules with separate requests would be bad for performance.

A source tree of AMD-style modules can easily be compiled into a single resource with a tool like RequireJS Optimizer. This gives you the best of both worlds; while developing and testing you can load the modules separately, and get meaningful debugging information without resorting to source maps. You can make changes to a script and test it without rebuilding your project. In production, you can compile the modules into a single resource.

So when you guarantee that all needed JS modules are there on page load, I don’t see the need for something like AMD.

How do you guarantee that all needed modules are there on page load? If you use AMD modules, each module knows its own dependencies and you can point a tool like RequireJS Optimizer at a single entrypoint module and be done with it. You could also reuse the same modules in other apps (including single-page apps) without changing anything; the modules can be loaded individually or combined into single resources.

If you go the namespace route, you’ll need to track which modules are needed for each page, manage the entire dependency graph for each entrypoint module, and manage the compilation process yourself somehow.

In other words, the script loader is not the only benefit of AMD. The other major benefit is that each module is responsible for its own dependencies (rather than just assuming that some namespaces exist, and leaving it up to the developer to ensure that the required namespaces are set up before the module can do its thing).

The difference you make between single-page applications and multi-page sites may not be particularly relevant today. Most web apps are between those two: they have multiple pages, a common JavaScript code which is used on every or nearly every page, and some code used on specific pages only.

This makes your suggestion of serving a single minified JavaScript file per page less practical. You’ll end up with large files, and different files for every page, resulting in poor performance and increased bandwidth usage.

From here, there are three generic solutions:

1. Just throwing all JavaScript into one big minified file which is called from every page of the web app.

   This works well in most cases, but would become problematic if there is too much JavaScript or in some specific situations, such as a case where the home page doesn’t contain a lot of interactivity and is expected to be extremely fast.

2. Having one big minified file of common code called on every page and dedicated code on specific pages.

   This is an improvement when performance becomes an issue, but increases maintenance complexity. If the architecture is poor and/or inexperienced programmers are working on JavaScript code, this may quickly result in a mess.

3. Using require.js to load JavaScript on-demand. Here, all the complexity is handled by require.js, which means that developers can achieve performance similar to the second solution while focusing on the code rather than on the organization.

So to answer your question, using something like AMD simply allows to mitigate some of the complexity from developers while keeping performance footprint low.